Re: [Crash-utility] A bug in 'bt' triggered by 'gdb set disassembly-flavor intel'
----- 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