Afaik the kernel only shows the stack backtrace of the kernel stack
(of a task).
I wonder if there would be anything wrong with letting it show
the user task stack backtrace in certain cases.
Read the rest to see what I mean.
If kernel.print-fatal-signals has been enabled a crashing
application makes the kernel show this:
ca2/943: potentially unexpected fatal signal 11.
NIP: 144c LR: 1444 CTR:
REGS: ce73df50 TRAP: 0300 Not tainted (2.6.28)
MSR: d032 EE,PR,ME,IR,DR CR: 22000422 XER: 2000
DAR: d003, DSISR: 2200
TASK = ceb7a3e0[943] 'ca2' THREAD: ce73c000
GPR00: 000e bf963b30 48025450 000a 0ff0ac2c 22000422 0001 0ff5e6b0
GPR08: 0001 d003 1032 1001896c 0ffe9000
GPR16: 0ffca59c 1009b940 100a8b6a 100bf234 bfea22b8 100bf224
GPR24: 100bf008 1009b960 4801e858 4802dd34 4802e7e0 0ffec8d8 bf963b30
Call Trace:
Segmentation fault
#
It's a real pity the user task stack backtrace isn't shown.
We're dealing with some complex (3rd party) applications and I like to see a
user task stack backtrace.
(Of course the way to go here is to use a debugger (gdb) and
do a backtrace (with the coredump file).
However, debugging takes some time. Besides the info is there
it only needs to be shown. Often just this info is enough to
pinpoint the problem)
Obviously the arch/powerpc/kernel/process.c:show_stack function
isn't meant for doing this. It only shows the kernel stack.
Btw. this doesn't work in my case since validate_sp returns 0 (because
sp is assigned the user-space stack (bf963b30) while kernel stack starts at
ce73c000).
Though if it would work it isn't very usefull I guess since the crashing app
not enters kernel-mode (via sys-calls).
If I change arch/powerpc/kernel/process.c:show_stack (of kernel 2.6.28) like
this:
do {
#if 0
if (!validate_sp(sp, tsk, STACK_FRAME_OVERHEAD))
return;
#endif
.
.
.
} while ((count++ kstack_depth_to_print) (sp != 0));
the following is shown:
ca2/943: potentially unexpected fatal signal 11.
NIP: 144c LR: 1444 CTR: c001fd7c
REGS: ce73df50 TRAP: 0300 Not tainted (2.6.28)
MSR: f932 EE,PR,FP,ME,IR,DR CR: 22000422 XER: 2000
DAR: d003, DSISR: 2200
TASK = cf09b340[943] 'ca2' THREAD: ce73c000
GPR00: 000e bfd65b30 48025450 000a 0ff0ac2c 22000422 0001 0ff5e6b0
GPR08: 0001 d003 1032 1001896c 0ffe9000
GPR16: 0ffca59c 1009b940 100a8b6a 100bf234 bfb532b8 100bf224
GPR24: 100bf008 1009b960 4801e858 4802dd34 4802e7e0 0ffec8d8 bfd65b30
Call Trace:
[bfd65b30] [1444] 0x1444 (unreliable)
[bfd65b60] [1490] 0x1490
[bfd65b90] [14cc] 0x14cc
[bfd65ba0] [0feb39c8] 0xfeb39c8
[bfd65dd0] [0feb3ad4] 0xfeb3ad4
[bfd65de0] [] 0x00
Segmentation fault
#
which is what I want.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev