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

[Ken Werner]

On 04/26/2012 11:51 AM, Harald Servat wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
>
> Al 26/04/12 11:40, En/na Ken Werner ha escrit:
> > 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
>
> Arun, Ken,
>
>    thank you very much for your comments (and test-cases!). I'll take a
> look into this when the machine becomes available again. What I can say
> for sure is that the application was not compiled with -funwind-tables.

You are welcome. :)
Keep in mind that an application is usually build from several objects - 
not just the object files created from the sourcecode of your 
application. For example the crt files and libgcc shipped with the 
toolchain or static/shared libraries that are linked in.

Without -funwind-tables libunwind relies on unwinding using the DWARF 
info only on modern ARM systems. In this case you could prevent 
libunwind from doing the APCS frame parsing via: UNW_ARM_UNWIND_METHOD=1.

There is also the possibilty that the signal frame detection fails for 
some reason. On ARM Linux (src/arm/Gis_signal_frame.c) libunwind looks 
at the current IP to the check if it points to a sigreturn sequence that 
was setup by the kernel. The sigreturn sequence itself depends on the 
signal type (rt vs non-rt) and the ABI (OABI, EABI, Thumb).

Regards,
Ken