• 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: Still can't figure out this overrelease bug
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Still can't figure out this overrelease bug


  • Subject: Re: Still can't figure out this overrelease bug
  • From: Pandaa <email@hidden>
  • Date: Thu, 16 Jun 2005 21:57:51 +0200


11 jun 2005 kl. 14.30 skrev Theodore H. Smith:

OK, well hows about this. If I use NSAutoReleasePool well enough, maybe I can pin this bug down?

I've never done this before, though, it just seems like it might be possible, from what I read. I'm not exactly sure yet on what additional bugs I might create by (badly) using NSAutoReleasePool.

... see below ->

Let's say I had this code:

NSAutoReleasePool* p = [[NSAutoReleasePool alloc]init];
NSString* s = [NSString stringWithCString : "hello"];

[p drain];
[self doStuffWith : s]; // crash.
[p release]; // we never get here

Something like that would a bug introduced by badly using NSAutoReleasePool, right?

.. ->

Then the problem becomes finding out which references to NSObjects I have for which lifetimes.

Let's (very theoretically) say then that I am able to perfectly figure out the lifetime of every NSObject I have.


NSAutoReleasePool* p = [[NSAutoReleasePool alloc]init]; NSString* s = [NSString stringWithCString : "hello"];

[s autorelease]; // over released!
[self doStuffWith : s];
[p drain]; // crash.
[p release];

In both examples, you are over-releasing the auto release pool. [p drain] both "Releases objects associated with the receiver, and then deallocates the receiver.", see the recent "Purpose of [NSAutoreleasePool drain]?" thread on this mailing list. Do one of [p drain] or [p release], but not both.


Would that then help me pin down my bug, by making the crash closer to the point where I overrelease?

That is possible. As Nick pointed out earlier, you don't need to crash hard but instead you can enable NSZombie from your main function like this:


#import <Cocoa/Cocoa.h>
#import <Foundation/NSDebug.h>

int main(int argc, char *argv[]) {
    NSZombieEnabled = YES;
    NSDeallocateZombies = NO;
    return NSApplicationMain(argc,  (const char **) argv);
}

Xcode will then print a message like "*** Selector 'release' sent to dealloced instance 0x3a16b0 of class MyClass. Break at '-[_NSZombie release]' to debug." in the run log when an object is over released.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. email@hidden . . www.synapticpulse.net .


_______________________________________________
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


References: 
 >Re: Still can't figure out this overrelease bug (From: "Theodore H. Smith" <email@hidden>)
 >Re: Still can't figure out this overrelease bug (From: "Theodore H. Smith" <email@hidden>)

  • Prev by Date: Re: Wrong type of button in IB?
  • Next by Date: Re: Wrong type of button in IB?
  • Previous by thread: Re: Still can't figure out this overrelease bug
  • Next by thread: Re: Cocoa-dev Digest, Vol 2, Issue 878
  • Index(es):
    • Date
    • Thread