Frustrating Cocoa bug

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Tord Kallqvist Romstad - 18 Jul 2006 13:30 GMT

I have an old chess program written using Cocoa and OpenMCL. Because
OpenMCL still doesn't work on the new Intel Macs, I am forced to
rewrite my program in Objective-C. The rewrite is mostly going fine,
but I have one very frustrating bug which I have no clue how to track
down. I have an initialization method with a signature like this:

-(id)initWithPGNString:(NSString *)string;

This method works perfectly when I feed it with a string read from a
file. However, when I feed it with exactly the same string read from
the pasteboard, the program crashes about 1/4 of the time. The exact
location of the crash varies. Sometimes it occurs in an apparently
random location in my own code, but most often it occurs in
objc_msgSend.

Another mysterious fact is that when I launch the program using
MallocDebug, the crashes never seem to occur.

Does anyone have any idea what the bug could be, and/or how to track
it down?

Signature

Tord Romstad

Reply to this Message

hns@computer.org - 18 Jul 2006 16:06 GMT

Tord Kallqvist Romstad schrieb:

> I have an old chess program written using Cocoa and OpenMCL. Because
> OpenMCL still doesn't work on the new Intel Macs, I am forced to
[quoted text clipped - 19 lines]
> --
> Tord Romstad

Looks like a alloc/release error in your implementation. You could try
to set NSZombieEnabled.

-- hns

Reply to this Message

Tord Kallqvist Romstad - 18 Jul 2006 17:57 GMT

> Looks like a alloc/release error in your implementation.

Yes, it has to be something like that. I still can't track it down,
though. :-(

> You could try to set NSZombieEnabled.

Thanks, I didn't know about NSZombieEnabled. It looks like a nice
tool for debugging this kind of problem. But where do I look for
error messages? I don't see anything unusual in XCode's "Run Log"
window after setting NSZombieEnabled=YES in the program's
environment. The output of my own NSLog() statements is all that
appears, and the program seems to behave in exactly the same way as
with NSZombieEnabled=NO.

Signature

Tord Romstad

Reply to this Message

Sean McBride - 20 Jul 2006 00:06 GMT

> > You could try to set NSZombieEnabled.
>
[quoted text clipped - 5 lines]
> appears, and the program seems to behave in exactly the same way as
> with NSZombieEnabled=NO.

<http://developer.apple.com/technotes/tn2004/tn2124.html#SECFOUNDATION>

Reply to this Message

Tord Kallqvist Romstad - 21 Jul 2006 20:24 GMT

> > > You could try to set NSZombieEnabled.
> >
[quoted text clipped - 7 lines]
>
> <http://developer.apple.com/technotes/tn2004/tn2124.html#SECFOUNDATION>

Yes, I found that technote. Unfortunately, it doesn't answer my
question of where to look for error messages (unless I am missing
something). When I set NSZombieEnabled to YES, no new error messages
are printed to stderr or the system log, so clearly they must be sent
somewhere else.

Signature

Tord Romstad

Reply to this Message

Sean McBride - 22 Jul 2006 22:16 GMT

> > > > You could try to set NSZombieEnabled.
> > >
[quoted text clipped - 13 lines]
> are printed to stderr or the system log, so clearly they must be sent
> somewhere else.

"any attempt to interact with a freed object will raise an exception"
... "You can use GDB to set a breakpoint on -[_NSZombie
methodSignatureForSelector:] to further debug this sort of problem"

No messages are logged. Basically you enable it and then run in the
debugger.

Reply to this Message

Tord Kallqvist Romstad - 25 Jul 2006 18:23 GMT

> > Yes, I found that technote. Unfortunately, it doesn't answer my
> > question of where to look for error messages (unless I am missing
[quoted text clipped - 7 lines]
>
> No messages are logged.

Why not? In my experience, all other uncaught exceptions are logged ...

> Basically you enable it and then run in the debugger.

I tried, but the breakpoint was never reached. It appears that either
NSZombieEnabled=YES for some mysterious reason doesn't work as
intended, or that my bug is something else.

Anyway, thanks for trying to help!

Signature

Tord Romstad

Reply to this Message

Doc O'Leary - 18 Jul 2006 17:03 GMT

> Does anyone have any idea what the bug could be, and/or how to track
> it down?

You probably aren't retaining the string, and at some point when it is
used the memory is overwritten enough to crap out. Odds are you're also
leaking memory in the file read if that source never seem to get stepped
on.

Signature

My personal UDP list: 127.0.0.1, 4ax.com, buzzardnews.com, googlegroups.com,
heapnode.com, localhost, x-privat.org

Reply to this Message

Tord Kallqvist Romstad - 18 Jul 2006 18:01 GMT

> > Does anyone have any idea what the bug could be, and/or how to track
> > it down?
>
> You probably aren't retaining the string, and at some point when it is
> used the memory is overwritten enough to crap out.

I don't think that is the problem. I am logging the retain count of
the string at the beginning and end of the method, and it is 1 in both
cases. This is true regardless of whether the string is read from a
file or from the pasteboard.

I never refer to the string again after the method has finished its work.

> Odds are you're also leaking memory in the file read if that source
> never seem to get stepped on.

I'll try to find out.

Thanks for your advice!

Signature

Tord Romstad

Reply to this Message

Mac Forum / Programming / Mac Programming / July 2006

Frustrating Cocoa bug