<div dir="ltr">Thanks, Jason!  That's good to know how it works in other cases.  <div><br></div><div>My unknown target situation should be going away shortly here once we move over to something based on the lldb-debugserver feeding better info to lldb.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 22, 2013 at 3:56 PM, Jason Molenda <span dir="ltr"><<a href="mailto:jmolenda@apple.com" target="_blank">jmolenda@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For what it's worth, the unwinder is picked in Thread::GetStackFrameStatus() - we have a "last resort" unwinder for Apple triples that tries to walk the stack by following a frame chain for i386 or x86_64.  Might be good to fall back to that even if the triple isn't -apple-.<br>

<br>
(wouldn't have helped in this case where you didn't even have an architecture, let alone an OS, defined, but fwiw.)<br>
<div class="im HOEnZb"><br>
On Nov 22, 2013, at 12:37 PM, Todd Fiala <<a href="mailto:tfiala@google.com">tfiala@google.com</a>> wrote:<br>
<br>
</div><div class="HOEnZb"><div class="h5">> Hi all,<br>
><br>
> I'm attaching a proposed patch to fix an issue where lldb will seg fault if for some reason there is no unwinder when StackFrameList::GetFramesUpTo() is called.<br>
><br>
> The scenario where I'm hitting it is more fundamentally broken (the triple is unknown) - this small patch is just to stop lldb from crashing.<br>
><br>
> Thanks!<br>
><br>
> Sincerely,<br>
> Todd Fiala<br>
</div></div><div class="HOEnZb"><div class="h5">> <null_unwinder.diff>_______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
<br>
</div></div></blockquote></div><br></div>