[Crash-utility] A bug in 'bt' triggered by 'gdb set disassembly-flavor intel'

[Dave Anderson]

----- Original Message -----
> 
> 
> 
> Hi Dave,
> 
> a colleague of mine has noticed a strange thing using crash-6.1.3: if
> we execute 'gdb set disassembly-flavor intel' first thing after
> starting crash (I duplicated this using this command interactively,
> he has it in his ~/.crashrc), this might add a bogus frame to 'bt'
> output.
> 
> The default behaviour (crash64 is crash-6.1.3 compiled from sources
> on x86_64):
> 
> $ crash64 vmlinux vmcore-2013-02-13-00.53.52
> 
> crash64 6.1.3
> ...
> crash64> bt 4131
> PID: 4131 TASK: ffff88041369a040 CPU: 0 COMMAND: "jbd2/dm-14-8"
> #0 [ffff88041443d810] machine_kexec at ffffffff8103284b
> #1 [ffff88041443d870] crash_kexec at ffffffff810ba982
> #2 [ffff88041443d940] oops_end at ffffffff81501b00
> #3 [ffff88041443d970] no_context at ffffffff81043bfb
> #4 [ffff88041443d9c0] __bad_area_nosemaphore at ffffffff81043e85
> #5 [ffff88041443da10] bad_area_nosemaphore at ffffffff81043f53
> #6 [ffff88041443da20] __do_page_fault at ffffffff810446b1
> #7 [ffff88041443db40] do_page_fault at ffffffff81503ade
> #8 [ffff88041443db70] page_fault at ffffffff81500e95
> [exception RIP: __jbd2_journal_remove_checkpoint+201]
> RIP: ffffffffa0299a09 RSP: ffff88041443dc20 RFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff8805e4c59bc0 RCX: 0000000000000000
> RDX: ffff8807fb6a4278 RSI: ffff88041443dcec RDI: ffff8807fb6a4278
> RBP: ffff88041443dc60 R8: 0000000000000001 R9: 00000000ffffffff
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000292
> R13: ffff8805e4c59c48 R14: ffff88041443dfd8 R15: ffff8807fb6a4278
> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
> #9 [ffff88041443dc68] journal_clean_one_cp_list at ffffffffa0299d84 [jbd2]
> #10 [ffff88041443dcc8] __jbd2_journal_clean_checkpoint_list at ffffffffa0299e3c [jbd2]
> #11 [ffff88041443dd28] jbd2_journal_commit_transaction at ffffffffa02978d1 [jbd2]
> #12 [ffff88041443de68] kjournald2 at ffffffffa029df78 [jbd2]
> #13 [ffff88041443dee8] kthread at ffffffff81091e06
> #14 [ffff88041443df48] kernel_thread at ffffffff8100c14a
> 
> Now exiting crash and starting it again:
 
> crash64> gdb set disassembly-flavor intel
> crash64> bt 4131
> PID: 4131 TASK: ffff88041369a040 CPU: 0 COMMAND: "jbd2/dm-14-8"
> #0 [ffff88041443d810] machine_kexec at ffffffff8103284b
> #1 [ffff88041443d870] crash_kexec at ffffffff810ba982
> #2 [ffff88041443d940] oops_end at ffffffff81501b00
> #3 [ffff88041443d970] no_context at ffffffff81043bfb
> #4 [ffff88041443d9c0] __bad_area_nosemaphore at ffffffff81043e85
> #5 [ffff88041443da10] bad_area_nosemaphore at ffffffff81043f53
> #6 [ffff88041443da20] __do_page_fault at ffffffff810446b1
> #7 [ffff88041443db40] do_page_fault at ffffffff81503ade
> #8 [ffff88041443db70] page_fault at ffffffff81500e95
> [exception RIP: __jbd2_journal_remove_checkpoint+201]
> RIP: ffffffffa0299a09 RSP: ffff88041443dc20 RFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff8805e4c59bc0 RCX: 0000000000000000
> RDX: ffff8807fb6a4278 RSI: ffff88041443dcec RDI: ffff8807fb6a4278
> RBP: ffff88041443dc60 R8: 0000000000000001 R9: 00000000ffffffff
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000292
> R13: ffff8805e4c59c48 R14: ffff88041443dfd8 R15: ffff8807fb6a4278
> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
> #9 [ffff88041443dc28] __journal_remove_journal_head at ffffffffa029ee22 [jbd2]
> #10 [ffff88041443dc68] journal_clean_one_cp_list at ffffffffa0299d84 [jbd2]
> #11 [ffff88041443dcc8] __jbd2_journal_clean_checkpoint_list at ffffffffa0299e3c [jbd2]
> #12 [ffff88041443dd28] jbd2_journal_commit_transaction at ffffffffa02978d1 [jbd2]
> #13 [ffff88041443de68] kjournald2 at ffffffffa029df78 [jbd2]
> #14 [ffff88041443dee8] kthread at ffffffff81091e06
> #15 [ffff88041443df48] kernel_thread at ffffffff8100c14a
> 
> As you see, now we have #9 that was not present while using the
> default flavour.
> 
> This is not a 6.1.3 regression - I tried an older binary (6.1.1) on
> the same vmcore and it behaves similarly.
> 
> Regards,
> Alex

I was not even aware of such a gdb setting.  And looking at what it
does to virtually every instruction line in the disassembly output,
I'm surprised that it doesn't wreak even more havoc.

My guess is that since it changes all "callq" instructions into "call"
instructions:

$ grep callq x86_64.c
 			if ((p1 = strstr(buf, "callq")) &&
        } else if (STREQ(argv[argc-2], "callq") &&
             	 *    callq  0xffffffffa0017aa0
$

it's going to confuse the by x86_64_function_called_by() and the
x86_64_dis_filter() functions, and in this particular case the
former.

Dave