Re: Thread ID in debugger window versus console
Re: Thread ID in debugger window versus console
- Subject: Re: Thread ID in debugger window versus console
- From: Peter Duniho <email@hidden>
- Date: Tue, 3 Feb 2009 10:12:55 -0800
Date: Mon, 2 Feb 2009 20:15:14 -0800
From: Michael Crawford <email@hidden>
On Mon, Feb 2, 2009 at 5:45 PM, Peter Duniho <email@hidden> wrote:
And barring that, is there some way in the debugger, once an
exception has
occurred (exception thrown, fault, etc.), to at least show the
thread where
the exception happened?
Place a breakpoint on the exception's constructor. If you don't know
for sure the extension type, placing a breakpoint on the
std::exception base class constructor might catch it, if you are so
fortunate that your exception is a subclass of it.
That's fine for the case where you have an easy-to-reproduce
exception. But in my question, I did specifically say "_once_ an
exception has occurred". I.e. it's already happened, and you must
determine the location in the code after the fact.
Fortunately, since I now know how to map one thread ID to another,
there's no need to use breakpoints to fake the information (pity the
poor programmer who is looking for an exception that occurs regularly,
but is only unhandled in one specific situation :) ). I can just look
at the output in the console where the exact thread is given.
Of course, why the debugger doesn't just highlight the thread where
the exception occurred when the process gets suspended by the
exception in the debugger, I have no idea. The debugger window shows
thread "1" and gdb shows the "current thread" as some arbitrary one,
rather than the thread where the exception occurred. Guess I should
file a feature request.
Thanks!
Pete
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden