Re: [Libunwind-devel] [PATCH 1/2] Restore the interpretation of the NULL %rbp location as end of frame chain.

[Lassi Tuura]

> Sorry, I do not understand what you wrote. I see exactly two places
> where a return from unw_step() with ret == 0 happens. First is the case
> of dwarf_step() returning non-negative value or null location for %rbp,
> at the block starting at line 83, as discussed above. Second case is the
> frame based unwinder, when unw_is_signal_frame() detected either signal
> or syscall frame (without dwarf annotations) but unw_handle_signal_frame
> failed.

I meant that 'unw_step()' ends in 'return ret' and the frame pointer
side has various code paths with assignments to 'ret' along the way,
mostly 'ret = dwarf_get(...)' which could inherit the 'ret' value all
the way to the end. These would have set ret <= 0, and it can only
reset to ret > 0 via successful tests on "there should be another
frame next". That's why I was interested in the debug output - thanks!

As Arun noted, it seems your situation is somehow triggered by the
null RIP after RIP=0x800e870a4. I'm glad it works for you now. At the
same time I'm still curious if unw_step() went one step too far, and
note with interest we've accumulated four different checks for null
RBP - but unfortunately can't help with that right now, as all my
linux/freebsd gear is in a bit, hum, disassembled right now.

L.