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: Jim Ingham <email@hidden>
- Date: Tue, 3 Feb 2009 11:35:34 -0800
I assume by exception you mean something like a EXC_BAD_ACCESS, or
some kind of UNIX signal? Something that would cause your program to
stop in the debugger...
If so, then the debugger is always supposed to stop and show you the
thread where the exception occurred. If it's not doing that that is a
bug, and please do file a bug report on it. It would be exceptionally
great if you could include a reproducible case in your bug. If you
can't then at least turn on the Xcode-gdb log (in the Debugging Pane
of the Xcode Preferences) and include the log in the bug you file. If
you could also indicate which thread you thought got the exception
that would be helpful.
On the off chance you're doing this, note that if you are using the
Unix "kill" system call to stop your program, that will generally stop
the main thread of your program. There's actually no guarantee which
thread that signal gets sent to... If you want to use Unix signals to
stop the program yourself, it's better to use pthread_kill and send
the signal to pthread_self().
Jim
On Feb 3, 2009, at 10:12 AM, Peter Duniho wrote:
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
_______________________________________________
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