Endless callstack in GetNumFrames

I was calling GetNumFrames on breaking in a lldb session which never seemed to return, breaking the debugger itself gives me:
http://pastebin.com/raw.php?i=00xVK5jL

as a callstack in the debugger. This is lldb from october or so. What could this be and what can I do about it?

There were some bugs that would cause infinite recursion in the unwinder, but all the ones we know about have been fixed. Does this happen it TOT lldb? It's not worth thinking very hard about this if it's a bug that's already fixed.

Jim

I believe Jason Molenda recently fixed this issue with revision 223843.

Greg Clayton schreef op 1/15/2015 om 7:29 PM:

I believe Jason Molenda recently fixed this issue with revision 223843.

Thanks greg, jim. I'll try updating.

Could be r223843 but this looks more like the kind of problem I was working on back in November (r221866, r222301, r222601) - it is a tricky bit of code in the unwinder. There's this feature I came up with when lldb fails to unwind out of a function, it tries using a fallback unwind scheme to see if it can get any further up the stack. Sometimes we have an oddball function that we can't backtrace out of correctly with all our normal mechanisms (e.g. an asynchronous signal handler where we don't have eh_frame describing how to find the saved register context) and the backtrace will terminate at that point. If we just blindly assumed the saved frame pointer / pc were saved on the stack, we could have gotten past it. Hence the fallback unwind plan system.

Are you seeing this with the top of tree lldb? Is it reproducible on Mac OS X? I'd be interested to know more details about what you're debugging.

J

jingham@apple.com schreef op 1/15/2015 om 7:24 PM:

There were some bugs that would cause infinite recursion in the unwinder, but all the ones we know about have been fixed. Does this happen it TOT lldb? It's not worth thinking very hard about this if it's a bug that's already fixed.

After upgrading to latest we do get a proper callstack, thanks.