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

[Kevin Modzelewski]

FYI both of us who've tried this patch are experiencing the issue on LLVM-jitted code, which is why there isn't dwarf information available.  Maybe I'll start another thread about my so-far-unsuccessful attempts to use _U_dyn_register...

I'm pretty new to this unwinding stuff, but it seems like even in the case that rbp=rsp, the unwinder is still making defined progress, since the return pointer got pushed on the stack above rbp.  ie even if rbp_of_current_frame = rsp_of_current_frame, then rsp_of_previous_frame = rbp_of_current_frame + 8, so rsp_of_previous_frame > rsp_of_current_frame and we shouldn't get stuck in a loop?

On Tue, May 13, 2014 at 10:10 AM, Arun Sharma <address@hidden> wrote:

On Tue, May 13, 2014 at 8:35 AM, Lassi Tuura <address@hidden> wrote:

> 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.

Yeah, we have protection against such an infinite loop later on in the
function. This check would apply only to the first such bad frame
without unwind info.

 -Arun