On Sat, Dec 20, 2014 at 6:18 AM, Tim Deegan <[email protected]> wrote:
>
> Hi all,
>
> While looking into a report about problems with libunwind unwinding
> from __lll_unlock_wake(), I noticed that I was getting some traces
> that didn't unwind at all, from one particular address in
> __lll_unlock_wake().
>
> On closer inspection, the one IP that fails is the first instruction
> in the function, and the failure is that c->use_pre_instr is set,
> causing the unwinder to look up the byte just before the function.
>
> I'm getting these traces from libprofiler/gperftools, which gets hold
> of the interrupted context in its signal handler (as a ucontext_t *)
> and passes it to unw_init_local() as its second argument.
> unw_init_local() unconditionally sets use_pre_instr, which is correct
> if the context came from unw_getcontext(), but not in this case.
>
> Disabling this path in libprofiler (and switching to a slower one that
> calls unw_getcontext() and then discards the first few frames) fixes
> the problem.
>
> Arguably this bug is in libprofiler, which ought not to be just
> passing a ucontext_t * to unw_init_local (though I see that the man
> page suggests this is OK for IA-64 at least).  But even so it would be
> good if libprofiler could use the signal context it already has,
> without setting use_prev_instr.
>

Hi. Thanks for reporting it. I was the guy who implemented that change in
libprofiler to use signal's ucontext_t. We had some bug reports suggesting
that occasionally libunwind crashes when unwinding across signal handler
boundary. And my thought was that passing ucontext_t that is passed to
signal handler would work around that. I.e. by pointing libunwind exactly
at frame right before signal handler frame.

Most likely original bug was only relevant for older systems and I've not
had any evidence that my change helps. So I'll simply revert that change in
profiler.
_______________________________________________
Libunwind-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/libunwind-devel

Reply via email to