Hi All, I try to use `bt -a' for arm64 platform, then Segmentation fault happened. My crash is built from source code hosted on github. And my kernel version is 4.4.35.

I tried to use gdb to examine this problem, Some information is shown as below: (gdb) bt #0 arm64_is_kernel_exception_frame (bt=bt@entry=0x7ffeba6577e0, stkptr=stkptr@entry=18446743803091823872) at arm64.c:1504 #1 0x00000000004fbda8 in arm64_back_trace_cmd (bt=0x7ffeba6577e0) at arm64.c:2259 #2 0x00000000004d415c in back_trace (bt=bt@entry=0x7ffeba6577e0) at kernel.c:3063 #3 0x00000000004dee87 in cmd_bt () at kernel.c:2701 [...] (gdb) p/x stkptr $14 = 0xffffffc0fded2d00 (gdb) p/x bt->stackbase $15 = 0xffffff8008dcc000 As it is, (stkptr - bt->stackbase) is too large. It lead bt->stackbuf[(ulong)(STACK_OFFSET_TYPE(stkptr))] index out of bounds. This stack belongs to swapper/0. I'm not sure whether it is a BUG. Could anyone give me some advise to solve this problem? Thank you!

-- Crash-utility mailing list Crash-utility(a)redhat.com https://www.redhat.com/mailman/listinfo/crash-utility

On Mon, Apr 17, 2017 at 09:05:12AM -0400, Dave Anderson wrote: > > > ----- Original Message ----- > > Hi All, > > > > I try to use `bt -a' for arm64 platform, then Segmentation fault > > happened. My crash is built from source code hosted on github. And my > > kernel version is 4.4.35. > > I note your reference to github, but what version of crash are you > using? > The only thing that comes to mind is this fix that went into > crash-7.1.8: > > - Fix for the ARM64 "bt" command in Linux 4.10 and later kernels that > are configured with CONFIG_THREAD_INFO_IN_TASK. Without the patch, > the "bt" command will fail for active tasks in dumpfiles that were > generated by the kdump facility. > (takahiro.akashi(a)linaro.org) > > But since you are using kernel version 4.4.35, that is presumably not > the problem. Thank you for rapid response. I'm using the most current code, which already contains this patch. Its version is 7.1.8++. > > > I tried to use gdb to examine this problem, Some information is shown > > as below: > > > > (gdb) bt > > #0 arm64_is_kernel_exception_frame (bt=bt@entry=0x7ffeba6577e0, > > stkptr=stkptr@entry=18446743803091823872) at arm64.c:1504 > > #1 0x00000000004fbda8 in arm64_back_trace_cmd (bt=0x7ffeba6577e0) at > arm64.c:2259 > > #2 0x00000000004d415c in back_trace (bt=bt@entry=0x7ffeba6577e0) at > kernel.c:3063 > > #3 0x00000000004dee87 in cmd_bt () at kernel.c:2701 > > [...] > > (gdb) p/x stkptr > > $14 = 0xffffffc0fded2d00 > > (gdb) p/x bt->stackbase > > $15 = 0xffffff8008dcc000 > > > > As it is, (stkptr - bt->stackbase) is too large. It lead > > bt->stackbuf[(ulong)(STACK_OFFSET_TYPE(stkptr))] index out of bounds. > > This stack belongs to swapper/0. I'm not sure whether it is a BUG. > > Could anyone give me some advise to solve this problem? Thank you! > > The closest sample arm64 kernel I have available is 4.5-based, and > looking > at the kernel virtual address space, both the stkptr and stackbase > values > above are out of range, so I'm not sure what's going on: > > crash> mach > MACHINE TYPE: aarch64 > MEMORY SIZE: 16 GB > CPUS: 1 > HZ: 1000 > PAGE SIZE: 65536 > KERNEL VIRTUAL BASE: ffff800000000000 > KERNEL VMALLOC BASE: ffff000000000000 > KERNEL MODULES BASE: ffff7ffffc000000 > KERNEL VMEMMAP BASE: ffff7fbfe0000000 > KERNEL STACK SIZE: 16384 > IRQ STACK SIZE: 16384 > IRQ STACKS: > CPU 0: ffff8003ffe30020 > CPU 1: ffff8003ffe60020 > CPU 2: ffff8003ffe90020 > CPU 3: ffff8003ffec0020 > CPU 4: ffff8003ffef0020 > CPU 5: ffff8003fff20020 > CPU 6: ffff8003fff50020 > CPU 7: ffff8003fff80020 > crash> I'm afraid I don't get you. Did you mean you cannot reproduce this phenomenon? Because the index is (stkptr - bt->stackbase). I think it should be OK if they are in the same range(both larger than PAGE_OFFSET of both smaller than PAGE_OFFSET). For my further inspect, Only bt 0 will crash. bt other thread is OK. I guess maybe swapper also should use stack address beyond PAGE_OFFSET (for my board, it's 0xffffffc000000000).