• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Thread ID in debugger window versus console
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 16:22:20 -0800

Ah, I see what's going on. You weren't actually launching your app in the debugger (gdb that is) but rather Xcode was running it directly. Then when your app crashed, Xcode caught the crash, and handed the process to gdb. gdb attached to it after it crashed, at which point the information about what thread crashed is lost. Xcode should have remembered that and told gdb which thread to set, but it doesn't at present.

Xcode will launch the program itself rather than let gdb do that either when you turn off the breakpoints or when you have no breakpoints to begin with. So if you debug with breakpoints on and put a breakpoint somewhere (like in main), when your program dies gdb will get the exception, and it will know what the right thread is, and it will tell Xcode about it.

This bug is fixed in a future release.

Jim

On Feb 3, 2009, at 2:45 PM, Peter Duniho wrote:

On Feb 3, 2009, at 12:37 PM, Jim Ingham wrote:

Well, I mean a Cocoa exception being thrown, so AFAIK not really like "EXC_BAD_ACCESS" or a Unix signal. But yes, "something that would cause your program to stop in the debugger".

By a Cocoa exception, you mean something thrown using [NSException raise:] or objc_exception_throw? Like an array out of bounds error or something like that.

I mean objc_exception_throw (in this case, NSInvalidArgumentException, but I'm not sure it matters).


Raising an ObjC exception won't normally cause your program to stop in the debugger unless you've either put a breakpoint on the throw functions, or if the exception unwinds all the way and causes the program to terminate.

The latter. The program does stop in the debugger, and gdb is in the console pretty clear that it's because of the exception, not something else interrupting the program at a later point.


Otherwise, you're probably stopping for some other reason later on that's unrelated to the throw...

But if you can get me a log I can probably tell what went on...

I've submitted the bug report, complete with gdb log (and I've filed a feature request bug on the gdb log preferences UI :p ). It is bug ID #6552724.


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
References: 
 >Re: Thread ID in debugger window versus console (From: Peter Duniho <email@hidden>)
 >Re: Thread ID in debugger window versus console (From: Jim Ingham <email@hidden>)
 >Re: Thread ID in debugger window versus console (From: Peter Duniho <email@hidden>)
 >Re: Thread ID in debugger window versus console (From: Jim Ingham <email@hidden>)
 >Re: Thread ID in debugger window versus console (From: Peter Duniho <email@hidden>)

  • Prev by Date: Re: lipo ((os/kern) invalid argument) error after building universal binary
  • Next by Date: Info.plist: ${PRODUCT_NAME} versus ${PRODUCT_NAME:identifier}
  • Previous by thread: Re: Thread ID in debugger window versus console
  • Next by thread: XCode built project crash related to .o files and p_threads?
  • Index(es):
    • Date
    • Thread