Corrupted tee in crash gdb
by Andi Kleen
Hi,
I have several crash dump files that reliably crash gdb inside crash.
This is with compressed dumps and recent kernels
It appears there is an error during the symbol processing (usually
when looking up runqueue, but even if you disable that it fails on
something else) and then gdb crashes because the tee
structure it uses to print error messages is corrupted. The tee fputs
vector is NULL and gdb jumps to zero while trying to print the
error message. So somehow crash doesn't set this up properly.
Using -minimal works, but that's too limiting.
I'm using this gdb patch to work around it by disabling the gdb errors.
That makes crash work well enough to look at most things.
It's probably not the correct fix, but at least it works for me.
diff -urp gdb-7.6-orig/gdb/ui-file.c gdb-7.6/gdb/ui-file.c
--- gdb-7.6-orig/gdb/ui-file.c 2020-12-22 09:48:27.532409801 -0800
+++ gdb-7.6/gdb/ui-file.c 2020-12-17 13:10:07.806799729 -0800
@@ -740,6 +740,8 @@ tee_file_flush (struct ui_file *file)
{
struct tee_file *tee = ui_file_data (file);
+ return;
+
if (tee->magic != &tee_file_magic)
internal_error (__FILE__, __LINE__,
_("tee_file_flush: bad magic number"));
@@ -752,6 +754,8 @@ tee_file_write (struct ui_file *file, co
{
struct tee_file *tee = ui_file_data (file);
+ return;
+
if (tee->magic != &tee_file_magic)
internal_error (__FILE__, __LINE__,
_("tee_file_write: bad magic number"));
@@ -764,9 +768,16 @@ tee_file_fputs (const char *linebuffer,
{
struct tee_file *tee = ui_file_data (file);
+ return;
+
if (tee->magic != &tee_file_magic)
internal_error (__FILE__, __LINE__,
_("tee_file_fputs: bad magic number"));
+ if (!tee->one->to_fputs) {
+ fputs(linebuffer, stdout);
+ return;
+ }
+
tee->one->to_fputs (linebuffer, tee->one);
tee->two->to_fputs (linebuffer, tee->two);
}
WARNING: kernel relocated [336MB]: patching 167186 gdb minimal_symbol
values
please wait... (patching 167186 gdb minimal_symbol values) [Detaching
after vfork from child process 1824671]
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
... up
#10 0x000000000066e75a in c_parse_internal () at c-exp.y:442
442 error (_("%s is not an ObjC Class"),
(gdb) p *tee
$2 = {ssize_t (int, int, size_t, unsigned int)} 0x7ffff7cc4a30 <tee>
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x00000000007b3f09 in tee_file_fputs (
linebuffer=0x23425f0 "No symbol \"runqueue\" in current context.\n",
file=<optimized out>)
at ui-file.c:770
#2 0x00000000007b071b in fputs_maybe_filtered (
linebuffer=linebuffer@entry=0x23425f0 "No symbol
\"runqueue\" in current context.\n",
stream=stream@entry=0x16c3ff0, filter=1) at utils.c:2091
#3 0x00000000007b08c1 in vfprintf_maybe_filtered
(stream=0x16c3ff0,
format=format@entry=0xa8f375 "%s\n",
args=args@entry=0x7ffffffe8828, filter=1, filter=1)
at utils.c:2332
#4 0x00000000007b0a2c in vfprintf_filtered
(args=0x7ffffffe8828, format=0xa8f375 "%s\n",
stream=<optimized out>) at utils.c:2392
#5 fprintf_filtered (stream=<optimized
out>, format=format@entry=0xa8f375 "%s\n")
at utils.c:2392
#6 0x00000000006f84f8 in throw_exception
(exception=...) at exceptions.c:234
#7 0x00000000006f874b in throw_it
(reason=reason@entry=RETURN_ERROR,
error=error@entry=GENERIC_ERROR,
fmt=<optimized out>,
ap=ap@entry=0x7ffffffe8978)
at exceptions.c:434
#8 0x00000000006f8956 in
throw_verror
(error=error@entry=GENERIC_ERROR,
fmt=<optimized out>,
ap=ap@entry=0x7ffffffe8978) at
exceptions.c:440
#9 0x00000000007af3e7 in error
(string=<optimized out>) at
utils.c:717
#10 0x000000000066e75a in
c_parse_internal () at
c-exp.y:442
#11 0x000000000066eab7 in
c_parse () at c-exp.y:3064
#12 0x0000000000723091 in
parse_exp_in_context
(stringptr=stringptr@entry=0x7ffffffea708,
#13 0x00000000007232b8 in parse_exp_1
(stringptr=stringptr@entry=0x7ffffffea758, pc=pc@entry=0,
block=block@entry=0x0, comma=comma@entry=0) at parse.c:1136
#14 0x00000000007232f9 in parse_expression (string=<optimized out>)
at parse.c:1279
#15 0x00000000006cf083 in gdb_get_datatype (req=0xdf8b20
<shared_bufs>) at symtab.c:5361
#16 gdb_command_funnel (req=0xdf8b20 <shared_bufs>) at symtab.c:5210
#17 0x0000000000518d4f in gdb_interface (req=0xdf8b20 <shared_bufs>)
at gdb_interface.c:397
#18 0x00000000005676dc in datatype_info (name=0x7ffffffec200
"runqueue", member=0x0,
dm=0x7ffffffeb000) at symbols.c:5635
#19 0x000000000056abe5 in arg_to_datatype (s=0x7ffffffec200
"runqueue", dm=0x7ffffffeb000,
flags=2) at symbols.c:6872
#20 0x000000000056f928 in get_array_length (s=0x90dcd6
"runqueue.cpu", two_dim=0x0, entry_size=0)
at symbols.c:8481
#21 0x00000000004f1092 in kernel_init () at kernel.c:338
#22 0x00000000004658a8 in main_loop () at main.c:781
#23 0x00000000006fa433 in captured_command_loop
(data=data@entry=0x0) at main.c:258
#24 0x00000000006f8c4a in catch_errors
(func=func@entry=0x6fa420 <captured_command_loop>,
func_args=func_args@entry=0x0,
errstring=errstring@entry=0x9617cf "",
mask=mask@entry=6)
at exceptions.c:557
#25 0x00000000006fb406 in captured_main
(data=data@entry=0x7fffffffd180) at main.c:1064
3 years, 8 months
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
3 years, 9 months
[PATCH 1/2] netdump: fix illegal read to already freed buffer
by HATAYAMA Daisuke
This issue was detected by valgrind as follows:
==1212== Invalid read of size 8
==1212== at 0x56C400: resize_elf_header (netdump.c:585)
==1212== by 0x56C400: is_netdump (netdump.c:363)
==1212== by 0x463571: main (main.c:561)
==1212== Address 0x4e8ec10 is 32 bytes inside a block of size 304 free'd
==1212== at 0x483BCE8: realloc (vg_replace_malloc.c:834)
==1212== by 0x56C393: resize_elf_header (netdump.c:547)
==1212== by 0x56C393: is_netdump (netdump.c:363)
==1212== by 0x463571: main (main.c:561)
==1212== Block was alloc'd at
==1212== at 0x4839809: malloc (vg_replace_malloc.c:307)
==1212== by 0x56C078: is_netdump (netdump.c:136)
==1212== by 0x463571: main (main.c:561)
==1212==
The issue was introduced by the commit
f42db6a33f0e0652df7cce8506352745b4794287 (Support core files with
"unusual" layout).
In resize_elf_header(), both elf32 and elf64 refer to the same address
as eheader, but when reallocating the address pointed at by eheader,
elf32 and elf64 are not updated, resulting in referring to the already
freed address.
To fix this issue, let's update elf32 and elf64 at the realloc().
Signed-off-by: HATAYAMA Daisuke <d.hatayama(a)fujitsu.com>
---
netdump.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/netdump.c b/netdump.c
index 2ca39e2..690f45e 100644
--- a/netdump.c
+++ b/netdump.c
@@ -550,6 +550,9 @@ resize_elf_header(int fd, char *file, char **eheader_ptr, char **sect0_ptr,
} else
*eheader_ptr = eheader;
+ elf32 = (Elf32_Ehdr *)&eheader[0];
+ elf64 = (Elf64_Ehdr *)&eheader[0];
+
if (FLAT_FORMAT()) {
if (!read_flattened_format(fd, 0, eheader, header_size))
return 0;
--
2.29.2
3 years, 10 months
[PATCH v2 0/7] zram related changes for zram support of crash gcore command
by HATAYAMA Daisuke
This patch set is to make changes I found necessary during development
of zram support for crash gcore command.
Here are tiny script and program I made to test the zram feature.
This may help your reviewing.
https://github.com/d-hatayama/some_stuff_for_crash_zram_devel
v2:
- Fix compilation error when without lzo library, which is fixed by
newly added 5-th patch to include zram even without lzo library.
- Add 6-th patch aiming to warn that given crash utility is built
without lzo library when encoutering zram pages.
HATAYAMA Daisuke (7):
diskdump, zram: cleanup try_zram_decompress()
diskdump, zram: initialize zram symbol information when needed
diskname, zram: fix fault error when reading zram disk with no symbol
information
diskname, zram: Notify necessity of loading zram module
zram: include zram code even without lzo library
zram: Add warning message when crash is built without lzo library
memory, zram: introduce and export readswap()
defs.h | 3 +-
diskdump.c | 234 ++++++++++++++++++++++++++++++++++++-------------------------
memory.c | 5 +-
3 files changed, 143 insertions(+), 99 deletions(-)
--
1.8.3.1
3 years, 10 months
Re: [Crash-utility] [PATCH v3 1/1] Support cross-compilation
by lijiang
Hi, Alexander
Thanks for the patch.
在 2020年11月08日 01:00, crash-utility-request(a)redhat.com 写道:
> Date: Fri, 6 Nov 2020 19:48:07 +0100
> From: Alexander Egorenkov <egorenar-dev(a)posteo.net>
> To: crash-utility(a)redhat.com
> Subject: [Crash-utility] [PATCH v3 1/1] Support cross-compilation
> Message-ID: <20201106184807.29574-1-egorenar-dev(a)posteo.net>
> Content-Type: text/plain; charset="US-ASCII"
>
> In order to support cross-compilation of crash-utilty,
> the configure tool compiled from configure.c must be built
> for the host architecture where the cross-compilation will run
> instead of the target architecture where the crash-utility shall run.
> Therefore, we need to support two C compilers in Maklefile,
> one for the host and one for the target. The old CC makefile variable
> shall represent the compiler for the target architecture and
> the new HOSTCC makefile variable shall represent the host compiler.
> Both variables differ only when a cross-compilation is performed.
> Furthermore, there must be a way to override the target architecture
> which is deduced from the preprocessor macros defined by the compiler
> used for the compilation of configure.c, because otherwise the configure
> tool will deduce host's architecture instead of the desired target.
> With the new preprocessor define CONF_DEFAULT_TARGET, it is possible to
> set the desired target architecture for the compiled crash-utility.
> When cross-compiling, set the makefile variable CROSS_COMPILE
> to the prefix of the cross-compiler and the default target
> architecture will be deduced from it, e.g. like this:
>
> make CROSS_COMPILE=s390x-linux-
>
After applied this patch, the cross build failed in Fedora as below:
[root@hpe-apollo-cn99xx-15-vm-21 crash]# make CROSS_COMPILE=s390x-linux-
...
rm -f ./libiberty.a pic/./libiberty.a
s390x-linux-ar rc ./libiberty.a \
./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o ./dwarfnames.o ./dyn-string.o ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o ./mkstemps.o ./objalloc.o ./obstack.o ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./safe-ctype.o ./simple-object.o ./simple-object-coff.o ./simple-object-elf.o ./simple-object-mach-o.o ./simple-object-xcoff.o ./sort.o ./spaces.o ./splay-tree.o ./stack-limit.o ./strerror.o ./strsignal.o ./timeval-utils.o ./unlink-if-ordinary.o ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o ./setproctitle.o
make[4]: s390x-linux-ar: Command not found
make[4]: *** [Makefile:247: libiberty.a] Error 127
make[3]: *** [Makefile:6996: all-libiberty] Error 2
make[2]: *** [Makefile:835: all] Error 2
crash build failed
make[1]: *** [Makefile:281: gdb_merge] Error 1
make: *** [Makefile:272: all] Error 2
[root@hpe-apollo-cn99xx-15-vm-21 crash]#
Can you help to check this patch again and do some coverage testing?
Thanks.
Lianbo
> and the default target architecture shall be S390X.
>
> Signed-off-by: Alexander Egorenkov <egorenar-dev(a)posteo.net>
> ---
>
> v2 -> v3:
> * Use CROSS_COMPILE makefile variable to pass cross-compiler prefix
>
> v1 -> v2:
> * Improved commit message
> * Added a note how to cross-compile crash-utilty to README
> * Moved CONF_CC makefile variable to correct place location
>
>
> Makefile | 53 +++++++++++++++++++++++++++++++++++++++++++++++++----
> README | 5 +++++
> configure.c | 39 +++------------------------------------
> 3 files changed, 57 insertions(+), 40 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index d185719..7185dcd 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -20,15 +20,60 @@
> PROGRAM=crash
>
> #
> -# Supported targets: X86 ALPHA PPC IA64 PPC64 SPARC64
> +# Supported targets: X86 X86_64 IA64 ALPHA PPC PPC64 ARM ARM64 SPARC64 MIPS S390 S390X
> # TARGET and GDB_CONF_FLAGS will be configured automatically by configure
> #
> TARGET=
> GDB_CONF_FLAGS=
>
> -ARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ -e s/arm.*/arm/ -e s/sa110/arm/)
> +ifneq ($(CROSS_COMPILE),)
> +ARCH := $(shell echo $(CROSS_COMPILE) | sed 's:^.*/::g' | cut -d- -f1)
> +else
> +ARCH := $(shell uname -m)
> +endif
> +ARCH := $(shell echo $(ARCH) | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ -e s/arm.*/arm/ -e s/sa110/arm/)
> +
> +CC = $(CROSS_COMPILE)gcc
> +HOSTCC = gcc
> +
> ifeq (${ARCH}, ppc64)
> -CONF_FLAGS = -m64
> +CONF_FLAGS += -m64
> +endif
> +
> +ifeq (${ARCH}, i386)
> +CONF_DEFAULT_TARGET := X86
> +else ifeq (${ARCH}, x86_64)
> +CONF_DEFAULT_TARGET := X86_64
> +else ifeq (${ARCH}, ia64)
> +CONF_DEFAULT_TARGET := IA64
> +else ifeq (${ARCH}, alpha)
> +CONF_DEFAULT_TARGET := ALPHA
> +else ifeq (${ARCH}, ppc)
> +CONF_DEFAULT_TARGET := PPC
> +else ifeq (${ARCH}, ppc64)
> +CONF_DEFAULT_TARGET := PPC64
> +else ifeq (${ARCH}, ppc64le)
> +CONF_DEFAULT_TARGET := PPC64
> +else ifeq (${ARCH}, arm)
> +CONF_DEFAULT_TARGET := ARM
> +else ifeq (${ARCH}, aarch64)
> +CONF_DEFAULT_TARGET := ARM64
> +else ifeq (${ARCH}, mips)
> +CONF_DEFAULT_TARGET := MIPS
> +else ifeq (${ARCH}, sparc64)
> +CONF_DEFAULT_TARGET := SPARC64
> +else ifeq (${ARCH}, s390)
> +CONF_DEFAULT_TARGET := S390
> +else ifeq (${ARCH}, s390x)
> +CONF_DEFAULT_TARGET := S390X
> +else
> +$(error unsupported architecture ${ARCH})
> +endif
> +
> +CONF_FLAGS += -DCONF_DEFAULT_TARGET=${CONF_DEFAULT_TARGET}
> +
> +ifneq ($(CROSS_COMPILE),)
> +CONF_FLAGS += -DGDB_TARGET_DEFAULT="\"GDB_CONF_FLAGS=--host=$(shell echo $(CROSS_COMPILE) | sed -e 's:^.*/::g' -e 's/-$$//')\""
> endif
>
> #
> @@ -288,7 +333,7 @@ force:
>
> make_configure: force
> @rm -f configure
> - @${CC} ${CONF_FLAGS} -o configure configure.c ${WARNING_ERROR} ${WARNING_OPTIONS}
> + @${HOSTCC} ${CONF_FLAGS} -o configure configure.c ${WARNING_ERROR} ${WARNING_OPTIONS}
>
> clean: make_configure
> @./configure ${CONF_TARGET_FLAG} -q -b
> diff --git a/README b/README
> index bfbaef6..f5bd476 100644
> --- a/README
> +++ b/README
> @@ -100,6 +100,11 @@
> o On an x86_64 host, an x86_64 binary that can be used to analyze
> ppc64le dumpfiles may be built by typing "make target=PPC64".
>
> + To cross-compile the crash utility, set the makefile variable CROSS_COMPILE to
> + the prefix of the cross-compiler, e.g. like this:
> +
> + $ make CROSS_COMPILE=s390x-linux-
> +
> Traditionally when vmcores are compressed via the makedumpfile(8) facility
> the libz compression library is used, and by default the crash utility
> only supports libz. Recently makedumpfile has been enhanced to optionally
> diff --git a/configure.c b/configure.c
> index 7f6d19e..970a547 100644
> --- a/configure.c
> +++ b/configure.c
> @@ -154,7 +154,9 @@ void add_extra_lib(char *);
> #define TARGET_CFLAGS_MIPS_ON_X86_64 "TARGET_CFLAGS=-m32 -D_FILE_OFFSET_BITS=64"
> #define TARGET_CFLAGS_SPARC64 "TARGET_CFLAGS="
>
> +#ifndef GDB_TARGET_DEFAULT
> #define GDB_TARGET_DEFAULT "GDB_CONF_FLAGS="
> +#endif
> #define GDB_TARGET_ARM_ON_X86 "GDB_CONF_FLAGS=--target=arm-elf-linux"
> #define GDB_TARGET_ARM_ON_X86_64 "GDB_CONF_FLAGS=--target=arm-elf-linux CFLAGS=-m32"
> #define GDB_TARGET_X86_ON_X86_64 "GDB_CONF_FLAGS=--target=i686-pc-linux-gnu CFLAGS=-m32"
> @@ -349,42 +351,7 @@ get_current_configuration(struct supported_gdb_version *sp)
> static char buf[512];
> char *p;
>
> -#ifdef __alpha__
> - target_data.target = ALPHA;
> -#endif
> -#ifdef __i386__
> - target_data.target = X86;
> -#endif
> -#ifdef __powerpc__
> - target_data.target = PPC;
> -#endif
> -#ifdef __ia64__
> - target_data.target = IA64;
> -#endif
> -#ifdef __s390__
> - target_data.target = S390;
> -#endif
> -#ifdef __s390x__
> - target_data.target = S390X;
> -#endif
> -#ifdef __powerpc64__
> - target_data.target = PPC64;
> -#endif
> -#ifdef __x86_64__
> - target_data.target = X86_64;
> -#endif
> -#ifdef __arm__
> - target_data.target = ARM;
> -#endif
> -#ifdef __aarch64__
> - target_data.target = ARM64;
> -#endif
> -#ifdef __mips__
> - target_data.target = MIPS;
> -#endif
> -#ifdef __sparc_v9__
> - target_data.target = SPARC64;
> -#endif
> + target_data.target = CONF_DEFAULT_TARGET;
>
> set_initial_target(sp);
>
> -- 2.29.2
3 years, 10 months
[PATCH] Fixed the segment fault when ikconfig passed nonstandard values
by Jackie Liu
From: Jackie Liu <liuyun01(a)kylinos.cn>
Some strange reasons may cause kcore to collect some strange
entries of ikconfig, such as CONFIG_SECU+[some hex data] causes
the 'val' to be NULL, and then crashes when strdup.
Signed-off-by: Jackie Liu <liuyun01(a)kylinos.cn>
---
kernel.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel.c b/kernel.c
index 9871637..aa86f0d 100644
--- a/kernel.c
+++ b/kernel.c
@@ -10244,6 +10244,9 @@ static void add_ikconfig_entry(char *line, struct ikconfig_list *ent)
sscanf(name, "CONFIG_%s", name);
val = strtok_r(NULL, "", &tokptr);
+ if (!val)
+ return;
+
ent->name = strdup(name);
ent->val = strdup(val);
}
--
2.17.1
3 years, 10 months
Re: [Crash-utility] [PATCH] arm64: update mapping symbol filter in arm64_verify_symbol
by lijiang
Hi, Qianli Zhao
Thanks for the patch.
在 2020年11月30日 18:22, crash-utility-request(a)redhat.com 写道:
> Message: 2
> Date: Mon, 30 Nov 2020 10:21:48 +0000
> From: ??? <zhaoqianli(a)xiaomi.com>
> To: "crash-utility(a)redhat.com" <crash-utility(a)redhat.com>
> Subject: [Crash-utility] [PATCH] arm64: update mapping symbol filter
> in arm64_verify_symbol
> Message-ID: <e2360405c4aa4036908a840e943e8f5e(a)xiaomi.com>
> Content-Type: text/plain; charset="utf-8"
>
> From: Qianli Zhao <zhaoqianli(a)xiaomi.com>
>
> Name Meaning of mapping symbol:
> $x
> $x.<any...>
> Start of a sequence of A64 instructions
>
> $c
> $c.<any...>
> Start of a sequence of C64 instructions
>
> $d
> $d.<any...>
> Start of a sequence of data items (for example, a literal pool)
>
> Reference documents:
> https://documentation-service.arm.com/static/5f9a92f6b1a7c5445f28fee6?token=
>
> Signed-off-by: Qianli Zhao <zhaoqianli(a)xiaomi.com>
> ---
> When use crash-arm64 parsing kdump,"dis" command can not completely parse out the disassembly code(aarch64-objdump is ok),miss some assembly code at the end,such as below:
>
> The queued_spin_lock_slowpath() actual code segment of the function is from 0xffffffdf44b80d48 to ffffffecc41591d4,but "dis" command only dump from 0xffffffdf44b80d48 to 0xffffffdf44b80df0.
>
> crash> dis queued_spin_lock_slowpath
> 0xffffffdf44b80d48 <$x.1>: str x30, [x18],#8
> 0xffffffdf44b80d4c <queued_spin_lock_slowpath+4>: stp x29, x30, [sp,#-64]!
> ....
> 0xffffffdf44b80dec <queued_spin_lock_slowpath+164>: cbnz w10, 0xffffffdf44b80e9c
> 0xffffffdf44b80df0 <queued_spin_lock_slowpath+168>: nop
>
> The reason for the issue is that crash-tool thinks next vaild symbol is $x.3,but $x.* is a mapping symbol defined by ARM,this type of symbol needs skip.
>
> ffffffdf44b80d48 (T) queued_spin_lock_slowpath
> ffffffdf44b80df4 (t) $x.3
> ffffffdf44b80dfc (t) $x.5
> ffffffdf44b80e24 (t) $x.7
> ffffffdf44b80e2c (t) $x.9
> ffffffdf44b80f6c (t) $x.13
> ffffffdf44b80f74 (t) $x.15
> ffffffdf44b8102c (t) $x.19
> ffffffdf44b81034 (t) $x.21
> ffffffdf44b810e8 (t) $x.7
> ffffffdf44b810e8 (T) rt_mutex_adjust_pi
> ffffffdf44b8118c (t) $x.8
>
> This issue will mislead us to analyze assembly issue:
> [20332.505051] Call trace:
> [20332.505057] queued_spin_lock_slowpath+0x198/0x3a0---->//Beyond code segment?
> [20332.505063] do_raw_spin_lock+0x10c/0x12c
> [20332.505071] _raw_spin_lock_irqsave+0x3c/0x50
> [20332.505080] set_dspp_hist_irq_feature+0x180/0x1d4
> [20332.505089] sde_cp_crtc_setfeature+0x168/0x2f4
> [20332.505095] sde_cp_crtc_apply_properties+0x46c/0x76c
> [20332.505102] sde_crtc_atomic_begin+0x490/0x62c
> [20332.505111] drm_atomic_helper_commit_planes+0x5c/0x2bc
> [20332.505117] complete_commit+0xa0/0x264
> [20332.505123] _msm_drm_commit_work_cb+0x128/0x22c
> [20332.505130] kthread_worker_fn+0x110/0x1ac
> [20332.505136] kthread+0x160/0x170
> [20332.505143] ret_from_fork+0x10/0x18
>
>
> Reference documents(page 7):
> https://documentation-service.arm.com/static/5f9a92f6b1a7c5445f28fee6?token=
> ---
>
> arm64.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arm64.c b/arm64.c
> index fdf77bd..24fd91e 100644
> --- a/arm64.c
> +++ b/arm64.c
> @@ -510,9 +510,11 @@ arm64_verify_symbol(const char *name, ulong value, char type)
> ((type == 'a') || (type == 'n') || (type == 'N') || (type == 'U')))
> return FALSE;
>
> - if (STREQ(name, "$d") || STREQ(name, "$x"))
> + if (STREQ(name, "$d") || STRNEQ(name, "$d.") ||
> + STREQ(name, "$x") || STRNEQ(name, "$x.") ||
> + STREQ(name, "$c") || STRNEQ(name, "$c."))
> return FALSE;
This looks good according to the "Table 5.5: Mapping symbols" in the document.
Acked-by: Lianbo Jiang <lijiang(a)redhat.com>
> -
> +
> if ((type == 'A') && STRNEQ(name, "__crc_"))
> return FALSE;
>
> --
> 2.7.4
3 years, 11 months
[PATCH] arm64: update mapping symbol filter in arm64_verify_symbol
by 赵乾利
From: Qianli Zhao <zhaoqianli(a)xiaomi.com>
Name Meaning of mapping symbol:
$x
$x.<any...>
Start of a sequence of A64 instructions
$c
$c.<any...>
Start of a sequence of C64 instructions
$d
$d.<any...>
Start of a sequence of data items (for example, a literal pool)
Reference documents:
https://documentation-service.arm.com/static/5f9a92f6b1a7c5445f28fee6?token=
Signed-off-by: Qianli Zhao <zhaoqianli(a)xiaomi.com>
---
When use crash-arm64 parsing kdump,"dis" command can not completely parse out the disassembly code(aarch64-objdump is ok),miss some assembly code at the end,such as below:
The queued_spin_lock_slowpath() actual code segment of the function is from 0xffffffdf44b80d48 to ffffffecc41591d4,but "dis" command only dump from 0xffffffdf44b80d48 to 0xffffffdf44b80df0.
crash> dis queued_spin_lock_slowpath
0xffffffdf44b80d48 <$x.1>: str x30, [x18],#8
0xffffffdf44b80d4c <queued_spin_lock_slowpath+4>: stp x29, x30, [sp,#-64]!
....
0xffffffdf44b80dec <queued_spin_lock_slowpath+164>: cbnz w10, 0xffffffdf44b80e9c
0xffffffdf44b80df0 <queued_spin_lock_slowpath+168>: nop
The reason for the issue is that crash-tool thinks next vaild symbol is $x.3,but $x.* is a mapping symbol defined by ARM,this type of symbol needs skip.
ffffffdf44b80d48 (T) queued_spin_lock_slowpath
ffffffdf44b80df4 (t) $x.3
ffffffdf44b80dfc (t) $x.5
ffffffdf44b80e24 (t) $x.7
ffffffdf44b80e2c (t) $x.9
ffffffdf44b80f6c (t) $x.13
ffffffdf44b80f74 (t) $x.15
ffffffdf44b8102c (t) $x.19
ffffffdf44b81034 (t) $x.21
ffffffdf44b810e8 (t) $x.7
ffffffdf44b810e8 (T) rt_mutex_adjust_pi
ffffffdf44b8118c (t) $x.8
This issue will mislead us to analyze assembly issue:
[20332.505051] Call trace:
[20332.505057] queued_spin_lock_slowpath+0x198/0x3a0---->//Beyond code segment?
[20332.505063] do_raw_spin_lock+0x10c/0x12c
[20332.505071] _raw_spin_lock_irqsave+0x3c/0x50
[20332.505080] set_dspp_hist_irq_feature+0x180/0x1d4
[20332.505089] sde_cp_crtc_setfeature+0x168/0x2f4
[20332.505095] sde_cp_crtc_apply_properties+0x46c/0x76c
[20332.505102] sde_crtc_atomic_begin+0x490/0x62c
[20332.505111] drm_atomic_helper_commit_planes+0x5c/0x2bc
[20332.505117] complete_commit+0xa0/0x264
[20332.505123] _msm_drm_commit_work_cb+0x128/0x22c
[20332.505130] kthread_worker_fn+0x110/0x1ac
[20332.505136] kthread+0x160/0x170
[20332.505143] ret_from_fork+0x10/0x18
Reference documents(page 7):
https://documentation-service.arm.com/static/5f9a92f6b1a7c5445f28fee6?token=
---
arm64.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arm64.c b/arm64.c
index fdf77bd..24fd91e 100644
--- a/arm64.c
+++ b/arm64.c
@@ -510,9 +510,11 @@ arm64_verify_symbol(const char *name, ulong value, char type)
((type == 'a') || (type == 'n') || (type == 'N') || (type == 'U')))
return FALSE;
- if (STREQ(name, "$d") || STREQ(name, "$x"))
+ if (STREQ(name, "$d") || STRNEQ(name, "$d.") ||
+ STREQ(name, "$x") || STRNEQ(name, "$x.") ||
+ STREQ(name, "$c") || STRNEQ(name, "$c."))
return FALSE;
-
+
if ((type == 'A') && STRNEQ(name, "__crc_"))
return FALSE;
--
2.7.4
#/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/#
3 years, 11 months
Calculating CPU time consumed by a process in its current run
by sandeep kumar Mantrala
I see an option in runq to check the time of the processes in the runq
help runq
-m Display the amount of time that the active task on each cpu has
been
running, expressed in a format consisting of days, hours, minutes,
seconds and milliseconds.
Is this time the time the process has been running in this instance? Or is
it the complete time the process had CPU?
Example :
crash> runq -m
CPU 0: [0 00:00:00.000] PID: 48 TASK: ffff88045a0bcd80 COMMAND:
"khungtaskd"
CPU 1: [0 00:00:02.155] PID: 21 TASK: ffff88045a74ec80 COMMAND:
"ksoftirqd/1"
CPU 2: [2 08:03:10.267] PID: 0 TASK: ffff88045a71ec80 COMMAND:
"swapper/2"
CPU 3: [2 08:03:10.267] PID: 0 TASK: ffff88045a748000 COMMAND:
"swapper/3"
For ksoftirqd/1 it says the time is 2 seconds 155 ms
What exactly is this time? The time in the current run or is it the
complete CPU time of this process since boot?
-------
Also I was trying to find the same using task_struct
crash> task 21
...
exec_start = 201790266578639,
sum_exec_runtime = 264131400786,
vruntime = 18446744073703683341,
prev_sum_exec_runtime = 35796104514,
...
it seems like, sum_exec_runtime - prev_sum_exec_runtime should give me the
time(in ns) that this process has been running in its current run
sum_exec_runtime - prev_sum_exec_runtime = 264131400786 - 35796104514 = 228
seconds
228 seconds is very different from what i see in runq -m
Can I please get some help on understanding and interpreting these times?
Any alternate methods will also be very helpful.
Thank you
Sandeep
3 years, 11 months
Re: [Crash-utility] [PATCH] extensions/eppic.mk: Remove ping checkto github.com
by lijiang
在 2020年12月23日 01:00, crash-utility-request(a)redhat.com 写道:
> Date: Mon, 21 Dec 2020 23:54:26 +0000
> From: HAGIO KAZUHITO(?????) <k-hagio-ab(a)nec.com>
> To: lijiang <lijiang(a)redhat.com>, "crash-utility(a)redhat.com"
> <crash-utility(a)redhat.com>
> Subject: Re: [Crash-utility] [PATCH] extensions/eppic.mk: Remove ping
> check to github.com
> Message-ID:
> <OSBPR01MB1991A487EDD6CA590B2959D5DDC00(a)OSBPR01MB1991.jpnprd01.prod.outlook.com>
>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Lianbo,
>
>> -----Original Message-----
>> From: lijiang <lijiang(a)redhat.com>
>> Sent: Monday, December 21, 2020 11:48 PM
>> To: crash-utility(a)redhat.com; HAGIO KAZUHITO(?????) <k-hagio-ab(a)nec.com>
>> Subject: Re:[PATCH] extensions/eppic.mk: Remove ping check to github.com
>>> Without this patch, in an environment where ping to github.com does
>>> not work, building eppic.so fails with the message "eppic.so: failed
>>> to pull eppic code from git repo" and "make clean" at the top-level
>>> crash directory unnecessarily takes about 10 seconds every time.
>>>
>>> $ time make clean
>>> ...
>>> real 0m10.398s
>>>
>> This change is very helpful.
>>
>>> Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
>>> ---
>>> extensions/eppic.mk | 5 +----
>>> 1 file changed, 1 insertion(+), 4 deletions(-)
>>>
>>> diff --git a/extensions/eppic.mk b/extensions/eppic.mk
>>> index c79170a596b7..7486ce46a6b8 100644
>>> --- a/extensions/eppic.mk
>>> +++ b/extensions/eppic.mk
>>> @@ -24,7 +24,6 @@ ifeq ($(TARGET), X86)
>>> endif
>>>
>>> APPFILE=eppic/applications/crash/eppic.c
>>> -GITHUB := $(shell ping -c 1 github.com | grep "1 received")
>> BTW: Is it possible to fix this issue with the option -W? For example:
>>
>> GITHUB := $(shell ping -c 1 -W 2 github.com | grep "1 received")
>> ^^^^
> No, this doesn't solve the former issue in an environment where ping
> doesn't work but "git clone" does work. I have such an environment..
>
Interesting. Seems that ping doesn't work because of the network policy
or other reason?
For my side, the -W option will provide a timeout.
> In the first place, what is the ping check needed for? I'm not sure
> why it is there. If it's for avoiding long timeout of "git clone",
> it would not be solved by the ping check everywhere, i.e. in a place
> where ping works but git clone doesn't work. In this case, something
> like "timeout 20 git clone ..." might be better.
>
This still depends on the network speed.
Anyway, this change looks good. Acked-by: Lianbo Jiang <lijiang(a)redhat.com>
> Thanks,
> Kazu
>
>
3 years, 11 months
