[PATCH] Makefile: reduce crash build log
by HAGIO KAZUHITO(萩尾 一仁)
Currently the verbose output of tar command when extracting the
GDB source files occupies more than half of crash build log.
It is not so helpful and makes the build log longer needlessly
especially on CI build test. Let's stop it.
Also reduce about 600 lines of crash build log with wget's
"--progress=dot:mega" option when stderr is not a tty.
Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
---
current log:
https://travis-ci.org/github/k-hagio/crash/jobs/759585719
with this patch:
https://travis-ci.org/github/k-hagio/crash/jobs/759589437
Makefile | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index f66eba7418d1..b3c0d3a7f75b 100644
--- a/Makefile
+++ b/Makefile
@@ -258,8 +258,9 @@ gdb_unzip:
@if [ ! -f ${GDB}.tar.gz ] && [ ! -f /usr/bin/wget ]; then \
echo /usr/bin/wget is required to download ${GDB}.tar.gz; echo; exit 1; fi
@if [ ! -f ${GDB}.tar.gz ] && [ -f /usr/bin/wget ]; then \
- wget http://ftp.gnu.org/gnu/gdb/${GDB}.tar.gz; fi
- @tar --exclude-from gdb.files -xvzmf ${GDB}.tar.gz
+ [ ! -t 2 ] && WGET_OPTS="--progress=dot:mega"; \
+ wget $$WGET_OPTS http://ftp.gnu.org/gnu/gdb/${GDB}.tar.gz; fi
+ @tar --exclude-from gdb.files -xzmf ${GDB}.tar.gz
@make --no-print-directory gdb_patch
gdb_patch:
--
2.18.4
4 years, 1 month
[PATCH v2] log: fix log level print in older kernels
by John Pittman
In older kernels, the log level and the log flags/facility are not
separated. Since the log level is only the last three bits, and the
flags/facility and level are separated in the upstream kernel, only
print those last three bits when using 'log -m'.
Suggested-by: David Jeffery <djeffery(a)redhat.com>
Signed-off-by: John Pittman <jpittman(a)redhat.com>
---
defs.h | 1 +
help.c | 7 ++++---
kernel.c | 2 ++
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/defs.h b/defs.h
index 35cdac2..35b983a 100644
--- a/defs.h
+++ b/defs.h
@@ -5627,6 +5627,7 @@ void clone_bt_info(struct bt_info *, struct bt_info *, struct task_context *);
void dump_kernel_table(int);
void dump_bt_info(struct bt_info *, char *where);
void dump_log(int);
+#define LOG_LEVEL(v) ((v) & 0x07)
#define SHOW_LOG_LEVEL (0x1)
#define SHOW_LOG_DICT (0x2)
#define SHOW_LOG_TEXT (0x4)
diff --git a/help.c b/help.c
index 587c717..62e27d0 100644
--- a/help.c
+++ b/help.c
@@ -3904,10 +3904,11 @@ char *help_log[] = {
" -d Display the dictionary of key/value pair properties that are optionally",
" appended to a message by the kernel's dev_printk() function; only",
" applicable to the variable-length record format.",
-" -m Display the message log level in brackets preceding each message. For",
+" -m Display the message log level in brackets preceding each message. For",
" the variable-length record format, the level will be displayed in ",
-" hexadecimal, and depending upon the kernel version, also contains the",
-" facility or flags bits.",
+" hexadecimal. In older kernels, by default, the facility/flag bits ",
+" will be stripped to only show the level, but if needed, can still be ",
+" shown with 'set debug 1'.",
" -a Dump the audit logs remaining in kernel audit buffers that have not",
" been copied out to the user-space audit daemon.",
" ",
diff --git a/kernel.c b/kernel.c
index ac765e3..735263c 100644
--- a/kernel.c
+++ b/kernel.c
@@ -5262,6 +5262,8 @@ dump_log_entry(char *logptr, int msg_flags)
fprintf(fp, "%s", buf);
}
+ level = LOG_LEVEL(level);
+
if (msg_flags & SHOW_LOG_LEVEL) {
sprintf(buf, "<%x>", level);
ilen += strlen(buf);
--
2.17.2
4 years, 1 month
Re: [Crash-utility] [PATCH v1 0/3] Add valgrind support for the crash's custom memory
by lijiang
Hi, HATAYAMA
在 2021年01月21日 12:47, crash-utility-request(a)redhat.com 写道:
> From: HATAYAMA Daisuke <d.hatayama(a)fujitsu.com>
> Sent: Monday, January 4, 2021 14:28
> To: crash-utility(a)redhat.com
> Cc: Hatayama, Daisuke/?? ??
> Subject: [PATCH v1 0/3] Add valgrind support for the crash's custom memory
>
> This patch set adds valgrind support for the crash's custom memory
> allocator. The motivation comes from investigation at
> https://github.com/crash-utility/crash-extensions/issues/1.
>
> The 1st patch implements the valgrind support, while 2nd and 3rd fixes
> the actual issues on the crash's custom memory allocator detected by
> valgrind.
>
> HATAYAMA Daisuke (3):
> Add valgrind support for the crash's custom memory allocator
> symbols: Fix potential read to already freed object
> tools: Fix potential write to object of 0 size
>
Thank you for the patchset.
This changes are fine to me, but I have some other concerns as below:
[1] add a simple description for supporting 'make valgrind' in README?
[2] only pass the '-DVALGRIND' when using 'make valgrind' explicitly?
For example:
Step1: [root@dell-pet620-01 crash]# make valgrind
TARGET: X86_64
CRASH: 7.2.9++
GDB: 7.6
cc -c -g -DX86_64 -DVALGRIND -DGDB_7_6 build_data.c -Wall -O2 -Wstrict-prototypes -Wmissing-prototypes -fstack-protector -Wformat-security
cc -c -g -DX86_64 -DVALGRIND -DGDB_7_6 tools.c -Wall -O2 -Wstrict-prototypes -Wmissing-prototypes -fstack-protector -Wformat-security
cc -c -g -DX86_64 -DVALGRIND -DGDB_7_6 global_data.c -Wall -O2 -Wstrict-prototypes -Wmissing-prototypes -fstack-protector -Wformat-security
^^^^^^^^^
...
Step2: [root@dell-pet620-01 crash]# make lzo
TARGET: X86_64
CRASH: 7.2.9++
GDB: 7.6
cc -c -g -DX86_64 -DVALGRIND -DLZO -DGDB_7_6 build_data.c -Wall -O2 -Wstrict-prototypes -Wmissing-prototypes -fstack-protector -Wformat-security
cc -c -g -DX86_64 -DVALGRIND -DLZO -DGDB_7_6 main.c -Wall -O2 -Wstrict-prototypes -Wmissing-prototypes -fstack-protector -Wformat-security
cc -c -g -DX86_64 -DVALGRIND -DLZO -DGDB_7_6 tools.c -Wall -O2 -Wstrict-prototypes -Wmissing-prototypes -fstack-protector -Wformat-security
^^^^^^^^^^^^^^^
...
For the 'make lzo', the cflag '-DVALGRIND' is also added here after the step1, is that expected?
BTW: this change could make the distribution add a new dependency of valgrind-devel package(A warm reminder).
Thanks.
Lianbo
> Makefile | 4 ++++
> configure.c | 15 ++++++++++++-
> symbols.c | 10 +++------
> tools.c | 72 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
> 4 files changed, 91 insertions(+), 10 deletions(-)
>
> --
> 1.8.3.1
4 years, 1 month
Is there a way to validate the coherency of a kdump-compressed dumpfile ?
by Agrain Patrick
Hello,
I'm trying to setup an analyze procedure (with scripts) and would like to 'check' the dumpfile before starting the interactive mode of 'crash'.
Is there a 'crash' option, command that would just :
* Return a status to say 'dumpfile is OK to be processed by crash'.
* Display a header that I could parse.
* Or ?
Or should I grab directly in the dumpfile (Hmm... kdump-compressed seems not to be easy to parse) ?
More possibilities with an ELF formatted dumpfile ?
Thanks.
Best regards,
Patrick Agrain
4 years, 1 month
[PATCH] log: fix log level print in older kernels
by John Pittman
In older kernels, the log level and the log priority are not
separated. Since the log level is only the last three bits,
print only those last three bits when using 'log -m'.
Suggested-by: David Jeffery <djeffery(a)redhat.com>
Signed-off-by: John Pittman <jpittman(a)redhat.com>
---
defs.h | 1 +
kernel.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/defs.h b/defs.h
index 35cdac2..35b983a 100644
--- a/defs.h
+++ b/defs.h
@@ -5627,6 +5627,7 @@ void clone_bt_info(struct bt_info *, struct bt_info *, struct task_context *);
void dump_kernel_table(int);
void dump_bt_info(struct bt_info *, char *where);
void dump_log(int);
+#define LOG_LEVEL(v) ((v) & 0x07)
#define SHOW_LOG_LEVEL (0x1)
#define SHOW_LOG_DICT (0x2)
#define SHOW_LOG_TEXT (0x4)
diff --git a/kernel.c b/kernel.c
index ac765e3..735263c 100644
--- a/kernel.c
+++ b/kernel.c
@@ -5262,6 +5262,8 @@ dump_log_entry(char *logptr, int msg_flags)
fprintf(fp, "%s", buf);
}
+ level = LOG_LEVEL(level);
+
if (msg_flags & SHOW_LOG_LEVEL) {
sprintf(buf, "<%x>", level);
ilen += strlen(buf);
--
2.17.2
4 years, 1 month
git repositories for gcore/trace commands under crash-utility project
by d.hatayama＠fujitsu.com
Hagio-san,
I'm now preparing for providing crash-gcore-command and
crash-trace-command packages in Fedora, which has been provided in
RHEL only so far.
Relevant to that, I'd like to talk about extensions/trace.c about
maintaining it in another independent git repository. Is it possible?
Having independent repository is useful to control versions between
upstream's and distribution's.
I'm now also attempting to put the git repository for crash gcore
command in public, that has been managed locally in our company in
private. Is it possible to move it under crash utility project,
https://github.com/crash-utility, like crash-utility/gcore or
crash-utility/extension-gcore?
Thanks.
HATAYAMA, Daisuke
4 years, 1 month
[PATCH v1 0/3] Add valgrind support for the crash's custom memory
by HATAYAMA Daisuke
This patch set adds valgrind support for the crash's custom memory
allocator. The motivation comes from investigation at
https://github.com/crash-utility/crash-extensions/issues/1.
The 1st patch implements the valgrind support, while 2nd and 3rd fixes
the actual issues on the crash's custom memory allocator detected by
valgrind.
HATAYAMA Daisuke (3):
Add valgrind support for the crash's custom memory allocator
symbols: Fix potential read to already freed object
tools: Fix potential write to object of 0 size
Makefile | 4 ++++
configure.c | 15 ++++++++++++-
symbols.c | 10 +++------
tools.c | 72 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
4 files changed, 91 insertions(+), 10 deletions(-)
--
1.8.3.1
4 years, 2 months
