This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: last_100_frees.stp on aarch64 is crashing while doing sprint_ubacktrace()


On 06/19/2015 12:38 PM, Frank Ch. Eigler wrote:
> William Cohen <wcohen@redhat.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 ...

Hi Frank,

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:

commit 150f207589149d410687e914f27eeb3b46d68b3d
Author: Frank Ch. Eigler <fche@redhat.com>
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
> insufficient.

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.

-Will

> 
> 
>> 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]
>> [...]


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]