Re: [Libunwind-devel] crashes trying to get a backtrace from a signal handler (ARM)

[Sven Neumann]

On Fri, 2010-09-10 at 12:55 +0200, Lassi Tuura wrote:

> > over the last days I have found time to investigate the unwind problem
> > on the ARM platform further. It turned out that uClibc was built without
> > any debug information. So I have now changed that in the hope that this
> > would get the unwinder over __default_sa_restorer() from /lib/libc.so.0.
> > Unfortunately this didn't help and the backtrace is still stuck in this
> > function. As I explained earlier, getting a backtrace works fine if it
> > is invoked from normal code. Only backtraces generated from a signal
> > handler have this problem.
> > 
> > I have run this with UNW_DEBUG_LEVEL=1000 and generated a large file
> > with debug output. Since this file is definitely too large for this
> > list, I've uploaded it here:  http://svenfoo.org/misc/arm.unwind
> > 
> > It would be terrific if you guys could have a look at this output and/or
> > tell me what else I could try to make this work eventually.
> 
> I extracted the essential interesting parts of your trace below.

Thanks, I have taken the trace off-line now. If someone still needs it,
please let me know.

>  Observations:
> 
> 1) What looks like your stack report is actually one level below where
> unwind currently is. Are you reporting IP value after the unw_step()
> was taken?

Indeed, that was wrong. I've now changed my code to be more in line with
the example I found in the tests directory.

> 2) It ends at looking for IP=0x40859fe7, but __default_sa_restorer is
> at address 0x40859fe8, and previous function is setjmp at 0x40859fdc.
> 
> It looks like you are for some reason landing to one byte before the
> actual function. Subtracting one from the caller address is indeed the
> default logic when walking up the call tree: you have to back off into
> the call instruction itself, the function might end with the call, so
> it's valid to look at the byte after the call.
> 
> This means there is either no FDE for __default_sa_restorer at all, or
> it wasn't found because it doesn't extend to one byte before the
> function, which is needed for this special case. This is the direct
> reason for returning -10 (-UNW_ENOINFO).
> 
> Off the top of my head I don't recall how linux on x86/x86_64 sets
> this up. I think the return address is also to the beginning of the
> sigreturn, so maybe the FDE range extends one byte before?
> 
> Can you double check with readelf there is unwind info for
> __default_sa_restorer, and the exact bounds for it? At least in the
> output you quoted there is no no FDE for delta 0xbfe8 into libc.
> Nearest I found was bee8-0xbeec which is __aeabi_MB_CUR_MAX, and after
> that there should be __longjmp, __vfork, clone, __sigsetjmp, setjmp
> and _setjmp, in address order, before the __default_sa_restorer.

Here's the .debug_frame section for libc.so extracted by readelf:

 http://svenfoo.org/misc/libc.so.dwarf

> As far as I could tell from quick internet search
> __default_sa_restorer is an assembler stub, so it needs unwind info to
> be entered manually.

So it could be that uCLibc simply doesn't have this manual unwind info
then? I will search a little, perhaps there's a patch that fixes this.


Thanks for your help,
Sven