20 May, 2016
1 commit
-
scripts/decode_stacktrace.sh presently displays module symbols as
func+0x0ff/0x5153 [module]
Add a third argument: the pathname of a directory where the script
should look for the file module.ko so that the output appears asfunc (foo/bar.c:123) module
Without the argument or if the module file isn't found the script prints
such symbols as is without decoding.Signed-off-by: Konstantin Khlebnikov
Cc: Sasha Levin
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
05 Sep, 2015
1 commit
-
Fix the stack decoder for the ARM architecture.
An ARM stack is designed as :[ 81.547704] [] (bucket_find_contain) from [] (check_sync+0x40/0x4f8)
[ 81.559668] [] (check_sync) from [] (debug_dma_sync_sg_for_cpu+0x128/0x194)
[ 81.571583] [] (debug_dma_sync_sg_for_cpu) from [] (__videobuf_sThe current script doesn't expect the symbols to be bound by
parenthesis, and triggers the following errors :awk: cmd. line:1: error: Unmatched ( or \(: / (check_sync$/
[ 81.547704] (bucket_find_contain) from (check_sync+0x40/0x4f8)Fix it by chopping starting and ending parenthesis from the each symbol
name.As a side note, this probably comes from the function
dump_backtrace_entry(), which is implemented differently for each
architecture. That makes a single decoding script a bit a challenge.Signed-off-by: Robert Jarzmik
Cc: Sasha Levin
Cc: Russell King
Cc: Michal Marek
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
11 Jun, 2014
1 commit
-
Right now when people try to report issues in the kernel they send stack
dumps to eachother, which looks something like this:[ 6.906437] [] ? backtrace_test_irq_callback+0x20/0x20
[ 6.907121] [] dump_stack+0x52/0x7f
[ 6.907640] [] backtrace_regression_test+0x38/0x110
[ 6.908281] [] ? proc_create_data+0xa0/0xd0
[ 6.908870] [] ? proc_modules_init+0x22/0x22
[ 6.909480] [] do_one_initcall+0xc2/0x1e0
[...]However, most of the text you get is pure garbage.
The only useful thing above is the function name. Due to the amount of
different kernel code versions and various configurations being used,
the kernel address and the offset into the function are not really
helpful in determining where the problem actually occured.Too often the result of someone looking at a stack dump is asking the
person who sent it for a translation for one or more 'addr2line'
translations. Which slows down the entire process of debugging the
issue (and really annoying).The decode_stacktrace script is an attempt to make the output more
useful and easy to work with by translating all kernel addresses in the
stack dump into line numbers. Which means that the stack dump would
look like this:[ 635.148361] dump_stack (lib/dump_stack.c:52)
[ 635.149127] warn_slowpath_common (kernel/panic.c:418)
[ 635.150214] warn_slowpath_null (kernel/panic.c:453)
[ 635.151031] _oalloc_pages_slowpath+0x6a/0x7d0
[ 635.152171] ? zone_watermark_ok (mm/page_alloc.c:1728)
[ 635.152988] ? get_page_from_freelist (mm/page_alloc.c:1939)
[ 635.154766] __alloc_pages_nodemask (mm/page_alloc.c:2766)It's pretty obvious why this is better than the previous stack dump
before.Usage is pretty simple:
./decode_stacktrace.sh [vmlinux] [base path]
Where vmlinux is the vmlinux to extract line numbers from and base path
is the path that points to the root of the build tree, for example:./decode_stacktrace.sh vmlinux /home/sasha/linux/ < input.log > output.log
The stack trace should be piped through it (I, for example, just pipe
the output of the serial console of my KVM test box through it).Signed-off-by: Sasha Levin
Signed-off-by: Linus Torvalds
