[Crash-utility] [BUG?] failed to execute bt -a for arm64

Zhi-zhou Zhang zhizhouzhang at asrmicro.com
Mon Apr 17 14:20:00 UTC 2017


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 at 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 at entry=0x7ffeba6577e0,
> > stkptr=stkptr at 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 at 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).

> 
> Dave
>  
> 
> 
> 
> 
> 
>  
> > --
> > Crash-utility mailing list
> > Crash-utility at redhat.com
> > https://www.redhat.com/mailman/listinfo/crash-utility
> > 




More information about the Crash-utility mailing list