[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libunwind-devel] On "Unwinding through 0-length frames"

From: Lassi Tuura
Subject: Re: [Libunwind-devel] On "Unwinding through 0-length frames"
Date: Tue, 13 May 2014 17:35:50 +0200

I don't really have any substantial grounds to nack the change.

From what I recall, this code path was mainly used to unwind through glibc frames that don't (didn't?) have unwind info. IIRC virtually every stack had one or two such frames at the end of the trace ("top-most frame", or "start" of the stack, at least for the main thread).

I vaguely recall there were also common enough anomalies - mostly unwinds starting off with bad unwind info, e.g. from an async signal, reading stack wrong and going into random junk - that would cause stuck infinite traces with zero-size frames, with unwinder making no progress. I'm not entirely sure if it's possible to fully define "progress", but at least one of RIP or RSP/CFA should be changing? Zero size frame (no CFA movement) where the next unw_step will end up using the same RIP would be bad news, as would be a short cycle of RIP addresses with no CFA change.

Other than that, my only concern would be whether the fast trace needs to, or can be, taught to deal with such frames. As long as they don't happen in anything performance sensitive, it wouldn't matter - the fast trace would fall on the slow one, and everybody would be fine.

I'm not currently actively involved with the unwinding related stuff, and am not able to brush up on the details right now - and could easily be wrong. So please go ahead if it looks ok to you, maybe as long as we protect against zero progress frames? Also, I don't have any recent data on how likely missing / bad unwind data is these days for the general (non-jit) case.

On Tue, May 13, 2014 at 8:27 AM, Arun Sharma <address@hidden> wrote:
On Mon, May 12, 2014 at 4:03 PM, Kevin Modzelewski <address@hidden> wrote:
> Hi, here's the original email:

Thanks. Somehow this one email didn't make it into my inbox. Strange.

> This "rsp=rbp" situation can occur if you have a small function, which
> requires no stack-saved variables, that calls some other function that then
> unwinds.  Here's a contrived example:

This extra constraint came from commit 9e98f15e and looks safe to
relax as far as I can see. We hit this code path only when dwarf info
is missing/invalid. So the condition is hard to reproduce by modifying
tests/Ltest-bt.c for eg because compiler always generates valid unwind
info for me :)

I'll go ahead and apply the patch as long as Lassi (hope I got his
email id right) doesn't Nack it.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]