Re: [Libunwind-devel] unwind within a signal handler (in linux / arm)

[Ken Werner]

On 04/19/2012 05:44 PM, Harald Servat wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dear all,
>
>    I've just downloaded a GIT clone of the libunwind and installed it in
> a linux/ARM machine.
>
>    We use libunwind from an library that monitors an application. This
> library uses periodical sampling to collect some information (including
> the callstack). I've found that libunwind segfaults when is issued from
> the signal handler. I'm attaching the gdb output below.
>
>    Has anyone seen this issue before?
>
> Thank you in advance.
>
> warning: Breakpoint address adjusted from 0x4002eb25 to 0x4002eb24.
> Core was generated by `./mpi_ping'.
> Program terminated with signal 11, Segmentation fault.
> #0  dwarf_get (cursor=0xbe9edbf8) at ../include/tdep-arm/libunwind_i.h:114
> 114       *val = *(unw_word_t *) DWARF_GET_LOC (loc);
> (gdb) where
> #0  dwarf_get (cursor=0xbe9edbf8) at ../include/tdep-arm/libunwind_i.h:114
> #1  _ULarm_step (cursor=0xbe9edbf8) at arm/Gstep.c:228
> #2  0x4017e8c2 in trace_callers (time=<value optimized out>, offset=6,
> type=1) at calltrace.c:78
> #3  0x4017ebe6 in Extrae_SamplingHandler (address=0xbe9f1d50) at
> sampling.c:83
> #4  0x4017ec68 in TimeSamplingHandler (sig=<value optimized out>,
> siginfo=0x0, context=<value optimized out>) at sampling.c:151
> #5<signal handler called>
> #6  0x42112e9a in MPIDI_CH3I_Progress () from /usr/lib/libmpich.so.3
> #7  0x42160038 in MPID_nem_network_poll () from /usr/lib/libmpich.so.3
> #8  0x42160038 in MPID_nem_network_poll () from /usr/lib/libmpich.so.3
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Hi Harald,

It looks like libunwind wasn't able to walk a particular frame of the 
stack and segfaults when attempting to parse APCS frame (which won't 
work in case the ARM EABI is used). By default libunwind uses DWARF 
information. If that fails it tries to use the ARM specific unwind 
information (requires your code to be compiled with -funwind-tables) and 
as a last resort it falls back on APCS frame parsing. The unwind 
mechanism used by libunwind can be controlled at runtime using the 
following environment variable:
  UNW_ARM_UNWIND_METHOD=255
In case you want restrict libunwind to DWARF only:
  UNW_ARM_UNWIND_METHOD=1
To restrict it to ARM specific unwind information only:
  UNW_ARM_UNWIND_METHOD=4

Of course this doesn't explain why unwinding via DWARF and ARM-extbl 
failed in the first place. Maybe there is no correct DWARF information 
and this piece of code wasn't compiled with -funwind-tables but I'm just 
guessing. In case of signals there are a couple of things involved - the 
kernel version (pre-/post 2.6.18), the type of the signal (rt vs- 
non-rt) and so on. I've attached a simple testcase that would be easy to 
debug. Could you check whether it fails on your system?

Regards,
Ken

libunwind-test-simple-signal.tar.bz2
Description: application/bzip