[Crash-utility] [BUG} gdb disassembly-flavor affecting display of call stack.

[Dave Anderson]

----- Original Message -----
> Hello,
> 
> I've observed the following rather peculiar behavior of crash 7.1.3 (gdb
> 7.6).
> 
> crash> set ffff88000376d280
>     PID: 9615
> COMMAND: "jbd2/dm-32-8"
>    TASK: ffff88000376d280  [THREAD_INFO: ffff880002bdc000]
>     CPU: 2
>   STATE: TASK_UNINTERRUPTIBLE
> 
> 
> crash> gdb set disassembly-flavor intel
> crash> bt
> PID: 9615   TASK: ffff88000376d280  CPU: 2   COMMAND: "jbd2/dm-32-8"
>  #0 [ffff880002bdf9a8] __schedule at ffffffff81618404
>  #1 [ffff880002bdf9e0] __clone_and_map_data_bio at ffffffff8150af42
>  #2 [ffff880002bdfa40] schedule at ffffffff81618a8e
> crash> gdb set disassembly-flavor att
> crash> bt
> PID: 9615   TASK: ffff88000376d280  CPU: 2   COMMAND: "jbd2/dm-32-8"
>  #0 [ffff880002bdf9a8] __schedule at ffffffff81618404
>  #1 [ffff880002bdfa40] schedule at ffffffff81618a8e
>  #2 [ffff880002bdfa60] schedule_timeout at ffffffff8161b3e6
>  #3 [ffff880002bdfb20] io_schedule_timeout at ffffffff81618054
>  #4 [ffff880002bdfb50] bit_wait_io at ffffffff81619196
>  #5 [ffff880002bdfb60] __wait_on_bit at ffffffff81618f7d
>  #6 [ffff880002bdfbb0] out_of_line_wait_on_bit at ffffffff816190d8
>  #7 [ffff880002bdfc20] __wait_on_buffer at ffffffff811d13d8
>  #8 [ffff880002bdfc30] jbd2_journal_commit_transaction at ffffffff81270a45
>  #9 [ffff880002bdfe30] kjournald2 at ffffffff81275073
> #10 [ffff880002bdfec0] kthread at ffffffff810738fc
> #11 [ffff880002bdff50] ret_from_fork at ffffffff8161c75f
> 
> 
> How come setting the disassembly flavor (which should be just a
> presentation aid) affects the displaying of the callstack? It took me a
> while to correlate this behavior. It's also strange that this doesn't
> happen on all processes on a vmcore file but only on some, so far I
> haven't been able to find any clues as to which processes this applies to.

Because the x86_64 backtrace code parses gdb text disassembly output.

I haven't looked into which instance causes the symptom you're seeing, but 
it's presumably related to one of these cases, all of which pass disassembly
commands to gdb:

$ grep gdb_pass_through x86_64.c
        if (!gdb_pass_through(buf, pc->tmpfile2, GNU_RETURN_ON_ERROR)) {
	if (gdb_pass_through(buf, pc->tmpfile2, GNU_RETURN_ON_ERROR)) {
	if (!gdb_pass_through(buf1, pc->tmpfile, GNU_RETURN_ON_ERROR))
        if (!gdb_pass_through(buf, pc->tmpfile, GNU_RETURN_ON_ERROR))
        if (!gdb_pass_through(buf, pc->tmpfile2, GNU_RETURN_ON_ERROR)) {
$

Dave



> 
> Regards,
> Nikolay
>