[Crash-utility] Another backtrace problem when running into exception stack(x86_64)

[Dave Anderson]

----- "Hu Tao" <hutao at cn.fujitsu.com> wrote:

> Hi Dave,
> 
> When we run into exception stack(test module attached) and take a
> dumpfile by virsh dump, it seems crash doesn't show backtrace
> properly.

Did you forcibly crash the kernel first?  Or did you essentially take
a "live dump"?

Dave  
 
> crash shows:
> 
> crash> bt -a
> PID: 1115   TASK: ffff88001e082d60  CPU: 0   COMMAND: "bash"
>  #0 [ffff88001f8a3c58] schedule at ffffffff813e9a41
>  #1 [ffff88001f8a3c60] _raw_spin_unlock at ffffffff813eb486
>  #2 [ffff88001f8a3c70] vt_console_print at ffffffff8123fc17
>  #3 [ffff88001f8a3cf0] _raw_spin_unlock_irqrestore at ffffffff813eb4c3
>  #4 [ffff88001f8a3d10] _raw_spin_unlock_irqrestore at ffffffff813eb4c3
>  #5 [ffff88001f8a3d20] release_console_sem at ffffffff8103c6a6
>  #6 [ffff88001f8a3d50] vprintk at ffffffff8103cca0
>  #7 [ffff88001f8a3df0] printk at ffffffff813e90e4
>  #8 [ffff88001f8a3e50] __handle_sysrq at ffffffff8124585d
>  #9 [ffff88001f8a3e90] write_sysrq_trigger at ffffffff8124593f
> #10 [ffff88001f8a3eb0] proc_reg_write at ffffffff8112b9f0
> #11 [ffff88001f8a3f00] vfs_write at ffffffff810e9101
> #12 [ffff88001f8a3f40] sys_write at ffffffff810e9213
> #13 [ffff88001f8a3f80] system_call_fastpath at ffffffff81002a82
>     RIP: 00007f26509b2200  RSP: 00007fff188c9900  RFLAGS: 00010206
>     RAX: 0000000000000001  RBX: ffffffff81002a82  RCX:
> 0000000000000400
>     RDX: 0000000000000002  RSI: 00007f2651293000  RDI:
> 0000000000000001
>     RBP: 00007f2651293000   R8: 000000000000000a   R9:
> 00007f2651296700
>     R10: 00000000ffffffff  R11: 0000000000000246  R12:
> 00007f2650c57780
>     R13: 0000000000000002  R14: 0000000000000002  R15:
> 0000000000000000
>     ORIG_RAX: 0000000000000001  CS: 0033  SS: 002b
> 
> 
> The module's output:
> 
> [root at localhost ~]# insmod km_kprobe.ko 
> kprobe registered
> [root at localhost ~]# echo q > /proc/sysrq-trigger 
> SysRq : Show clockevent devices & pending hrtimers (no others)
> post_handler will loop.
> Pid: 1116, comm: bash Not tainted 2.6.36-rc6-00140-g183b469-dirty #5
> Call Trace:
>  <#DB> ffff880001a09da0     [<ffffffff8124552e>] ?
> sysrq_handle_show_timers+0x1/0xb
> ffff880001a09dc0     [<ffffffffa00ea017>] handler_post+0x17/0x1c
> [km_kprobe]
> ffff880001a09dd0     [<ffffffff813edb44>]
> kprobe_exceptions_notify+0x376/0x460
> ffff880001a09df0     [<ffffffff8124552d>] ?
> sysrq_handle_show_timers+0x0/0xb
> ffff880001a09e00     [<ffffffff813ed971>] ?
> kprobe_exceptions_notify+0x1a3/0x460
> ffff880001a09e40     [<ffffffff813ee7e7>]
> notifier_call_chain+0x32/0x5e
> ffff880001a09e80     [<ffffffff813ee850>]
> __atomic_notifier_call_chain+0x3d/0x6b
> ffff880001a09ec0     [<ffffffff813ee88d>]
> atomic_notifier_call_chain+0xf/0x11
> ffff880001a09ed0     [<ffffffff813ee8bd>] notify_die+0x2e/0x30
> ffff880001a09f00     [<ffffffff813ec035>] do_debug+0x93/0x156
> ffff880001a09f50     [<ffffffff813ebbb8>] debug+0x28/0x40
> ffff880001a09fd8     [<ffffffff8124552e>] ?
> sysrq_handle_show_timers+0x1/0xb
>  <<EOE>> ffff88001d99fe50     [<ffffffff8124585d>] ?
> __handle_sysrq+0xba/0x156
> ffff88001d99fe90     [<ffffffff8124593f>]
> write_sysrq_trigger+0x46/0x4e
> ffff88001d99fea0     [<ffffffff812458f9>] ?
> write_sysrq_trigger+0x0/0x4e
> ffff88001d99feb0     [<ffffffff8112b9f0>] proc_reg_write+0x8d/0xac
> ffff88001d99ff00     [<ffffffff810e9101>] vfs_write+0xa9/0x105
> ffff88001d99ff40     [<ffffffff810e9213>] sys_write+0x45/0x69
> ffff88001d99ff80     [<ffffffff81002a82>]
> system_call_fastpath+0x16/0x1b
> 
> Notice that two backtrace output differ from <<EOE>>, crash doesn't
> show
> exception stack frames. Although crash does check exception stack
> against sp, but the problem seems to be we can't get right sp value
> (ffff880001a09da0 in this example) from the dump file. Am I right? Is
> there any we can get right sp value from dump file?
> 
> I did a manually check on these stack frames using crash on the dump
> file(rd then sym), and the stack contents are the same as the
> module's
> output.
> 
> BTW, bt -S ffff880001a09da0 causes crash to seg fault.
> 
> -- 
> Thanks,
> Hu Tao