Re: crash on command-W

FROM : Ken Ferry
DATE : Tue Jun 10 18:24:35 2008

On Tue, Jun 10, 2008 at 8:24 AM, Jens Alfke <<email_removed>> 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.