> 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. _______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
