Re: Selector 'release' sent to dealloced instance of class NSDeviceRGBColor ??
Re: Selector 'release' sent to dealloced instance of class NSDeviceRGBColor ??
- Subject: Re: Selector 'release' sent to dealloced instance of class NSDeviceRGBColor ??
- From: Jonathan del Strother <email@hidden>
- Date: Sun, 2 Oct 2005 11:11:36 +0100
On 2 Oct 2005, at 01:03, Andy Lee wrote:
On Oct 1, 2005, at 7:31 PM, Jonathan del Strother wrote:
Selector 'release' sent to dealloced instance 0x8bb85b0 of class
NSDeviceRGBColor.
This occurs in the application's normal autorelease pool.
What's particularly odd about it is that there is nowhere where I
do any of my own memory management on an NSColor - I'm relying
entirely on class methods returning autoreleased objects. I don't
call retain, release, or autorelease on an NSColor in this program.
Are you able to pinpoint the line of code where the offending -
release message is sent? (I haven't used zombie mode much -- if it
throws exceptions, you could set a breakpoint using "br
[NSException raise]" in the debugger and that should show you where
it's happening.) If it's happening on an [x release] in your own
code, it's possible that x is still pointing to a block of memory
that earlier got dealloc'ed. This would suggest that you're over-
releasing x. targetRGB just happened to occupy that area of memory
later in the course of events.
I thought that NSZombie prevented memory deallocation, so there
should be no way for targetRGB's memory to later get occupied by
something else.
I think I've found the problem. This helpful page - http://
www.cocoadev.com/index.pl?DebuggingAutorelease - pointed out the
malloc_history tool, which I used to eventually track down a free()
operation on an NSString. Ooops. The NSString used to be a malloc'd
wchar, I must've missed that line when I changed everything over.
Anyway - mental note : using free() on an NSObject confuses the hell
out of the memory debug tools :)
Thanks for the suggestions, regardless.
Jon
_______________________________________________
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