On Tue, May 13, 2014 at 8:35 AM, Lassi Tuura <[email protected]> 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 _______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
