On Tue, Jun 10, 2008 at 8:24 AM, Jens Alfke <[EMAIL PROTECTED]> wrote: > > On 9 Jun '08, at 10:30 PM, James W. Walker wrote: > >> Tech Note 2124 says: "You can use GDB to set a breakpoint on -[_NSZombie >> methodSignatureForSelector:] to further debug this sort of problem." I >> tried pasting methodSignatureForSelector: into the breakpoints window, and >> it gave me a choice of a dozen or so classes containing such a method, none >> mentioning zombies. Is this Tech Note out of date, perhaps? > > In the breakpoints window, create a symbolic breakpoint with the entire > string "-[_NSZombie methodSignatureForSelector:]". > > Or if you prefer, at a gdb prompt enter > break -[_NSZombie methodSignatureForSelector:] > > (Is there really an _ before the class name?)
The tech note is out of date, actually. There should no longer be a need to set a breakpoint explicitly. Foundation will send a SIGTRAP signal and gdb will stop at that point. See the Foundation release notes: --- Changes to NSZombie debug mechanism NSZombieEnabled now works for general CFType objects, including toll-free bridged ones. If NSZombieEnabled is set to "YES", then the CFZombieLevel environment variable is ignored. In 10.5, when zombies are enabled, a message something like this is logged and a debugger trap is invoked: 2006-09-09 19:24:31.122 MyTestApp[402] *** -[NSURLConnection release]: message sent to deallocated instance 0x2141e30 Thus you do not have to set breakpoints on lots of potential methods and/or re-run the application (assuming you ran it under the debugger the first time) and try to reproduce the problem in order to find out where it is happening. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
