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 > On Jan 15, 2015, at 10:29 AM, Greg Clayton <gclay...@apple.com> wrote: > > I believe Jason Molenda recently fixed this issue with revision 223843. > > >> On Jan 15, 2015, at 8:06 AM, Carlo Kok <c...@remobjects.com> wrote: >> >> 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? >> >> -- >> Carlo Kok >> RemObjects Software >> _______________________________________________ >> lldb-dev mailing list >> lldb-dev@cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > _______________________________________________ > lldb-dev mailing list > lldb-dev@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
