This is the mail archive of the
mailing list for the systemtap project.
Re: last_100_frees.stp on aarch64 is crashing while doing sprint_ubacktrace()
- From: William Cohen <wcohen at redhat dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: systemtap at sourceware dot org, Mark Wielaard <mjw at redhat dot com>, Pratyush Anand <panand at redhat dot com>, Dave Long <dave dot long at linaro dot org>
- Date: Fri, 19 Jun 2015 17:01:10 -0400
- Subject: Re: last_100_frees.stp on aarch64 is crashing while doing sprint_ubacktrace()
- Authentication-results: sourceware.org; auth=none
- References: <55843208 dot 6030003 at redhat dot com> <y0mlhfflkl9 dot fsf at fche dot csb>
On 06/19/2015 12:38 PM, Frank Ch. Eigler wrote:
> William Cohen <email@example.com> writes:
>> [...] Any suggestions on how to further diagnose this? Other
>> nuggets of information available in the output below?
> Certainly. One would start from retaining a copy of the systemtap
> module, built with
> # stap -p4 -k -DDEBUG_UNWIND=2 -G CONFIG_DEBUGINFO=y ...
I did use -p4 -k for the stap modules and took a look at output earlier. The -DDEBUG_UNWIND=2 -G CONFIG_DEBUG_INFO=y are good additional suggestions to get a better understanding. The -DEBUG_UNWIND=2 looks like it might produce a bit too much output for this particular case. The -G CONFIG_DEBUGINFO=y doesn't have any effect. https://lwn.net/Articles/502773/ suggests -B CONFIG_DEBUG_INFO=y because of:
Author: Frank Ch. Eigler <firstname.lastname@example.org>
Date: Wed Mar 14 13:10:38 2012 -0400
PR13847: don't build debuginfo for stap modules
Suppressing the -g (by default) for stap_*.ko reduces compile time
and greatly reduces resulting .ko file size. Since stap modules
are not usually probed themselves, this is a good default.
* buildrun.cxx (make_any_make_cmd): Prefix kbuildflags with CONFIG_DEBUG_INFO=.
However, I can't seem to get the stap module to be built with debuginfo even with what seem like appropriate command line options.
> so one can apply normal post-mortem debugging techniques to the module
> (disassemble at the trapping address, deduce whether data or code is
> more suspect, etc.). dwarf-dump the target process to check the dwarf
> data by hand. Attempt run; collect vmcore and any panicy messages.
> runtime/unwind.c:processCFI() works its way through the dwarf data
> with some protection against e.g. bad data, but it may be
I recall Mark making some changes to make elf handling more robust in elfutils. I suspect similar robustification is missing somewhere in the systemtap unwinder code.
>> Jun 19 10:36:46 apm-mustang-ev3-11 kernel: Hardware name: AppliedMicro Mustang/Mustang, BIOS 1.1.0 Apr 22 2015
>> Jun 19 10:36:46 apm-mustang-ev3-11 kernel: task: fffffe01dda97300 ti: fffffe00bd960000 task.ti: fffffe00bd960000
>> Jun 19 10:36:46 apm-mustang-ev3-11 kernel: PC is at processCFI.constprop.119+0x77c/0x8d8 [stap_30b4cb5617d66b47c47d1ba687c18f92_2825]
>> Jun 19 10:36:46 apm-mustang-ev3-11 kernel: LR is at processCFI.constprop.119+0x75c/0x8d8 [stap_30b4cb5617d66b47c47d1ba687c18f92_2825]
>> Jun 19 10:36:46 apm-mustang-ev3-11 kernel: pc : [<fffffdfffc4fa2e0>] lr : [<fffffdfffc4fa2c0>] pstate: 20000145
>> Jun 19 10:36:46 apm-mustang-ev3-11 kernel: [<fffffdfffc4fa2e0>] processCFI.constprop.119+0x77c/0x8d8 [stap_30b4cb5617d66b47c47d1ba687c18f92_2825]
>> Jun 19 10:36:46 apm-mustang-ev3-11 kernel: [<fffffdfffc4fb3f4>] unwind_frame.constprop.115+0x44c/0xe1c [stap_30b4cb5617d66b47c47d1ba687c18f92_2825]