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.
Regards,
Nikolay
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
