• 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: Best way to debug (was retain/release/pointers question)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Best way to debug (was retain/release/pointers question)


  • Subject: Re: Best way to debug (was retain/release/pointers question)
  • From: "M. Uli Kusterer" <email@hidden>
  • Date: Sun, 5 Dec 2004 16:00:55 +0100

At 21:33 Uhr -0500 04.12.2004, Jonathan Jackel wrote:
This topic is probably more appropriate for the XCode list, and you'll likely get better responses there, but as nearly everyone here uses XCode, it's not insanely off-topic.

Basically the debugger window breaks down into three panes. There's a "thread" view in the upper left, a "variable" view at the upper right, and the editor at the bottom.

Note that you can customize the arrangement of the panes a little, so if it isn't that way on your computer, blame yourself ;-)


When your code stops on -[NSException raise] (BTW, you need that - or + at the begining when you create a symbolic breakpoint),

No you don't.

(gdb) fb [NSException raise]

 works just fine for me.

You'll also see a lot of greyed out methods -- those are methods from the Cocoa frameworks that you cannot look at with the debugger.

Well, you can, but you'll only get source code disassembly, which isn't half as much fun as getting the ObjC source code that this is equivalent to. But still, it can be quite educational.


If you click on one of non-greyed methods, the debugger editor will show you exactly where in that method execution was stopped. Start with the method at the top of the list and work your way down. As you do this, examine the relevant variables in the variable view. Usually this procedure (perhaps augmented with a few strategically placed additional breakpoints) provides enough information to figure out what's going on and fix it.

Of course, if it's a memory bug, e.g. you've accessed an object after you've released it, the actual point where your app breaks may be a long time after your actual mistake. E.g. when you prematurely release an object in applicationDidFinishLaunching:, and don't access it again until applicationWillTerminate:, your app will run just fine and crash when it quits, even though the actual error happened immediately after startup. That's why memory bugs are so hard to track down.


The core of the debugger is gdb -- XCode is basically a GUI for it. You can find out more information than you'd ever want to know by typing "man gdb" in the Terminal.

And then quite a bit more :-p

--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
       "The Witnesses of TeachText are everywhere..."
                   http://www.zathras.de
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Best way to debug (was retain/release/pointers question)
      • From: Keith Blount <email@hidden>
References: 
 >Re: Best way to debug (was retain/release/pointers question) (From: Keith Blount <email@hidden>)
 >Re: Best way to debug (was retain/release/pointers question) (From: Jonathan Jackel <email@hidden>)

  • Prev by Date: Problem with Document windows and automatic defaults
  • Next by Date: Re: Application crash in -[NSViewHierarchyLock lockForWriting]
  • Previous by thread: Re: Best way to debug (was retain/release/pointers question)
  • Next by thread: Re: Best way to debug (was retain/release/pointers question)
  • Index(es):
    • Date
    • Thread