Re: alloc init thread safe?
Re: alloc init thread safe?
- Subject: Re: alloc init thread safe?
- From: Jeff C <email@hidden>
- Date: Thu, 8 Mar 2007 19:34:25 -0500
The constructors in the code look highly suspect. Why aren't you
following the common pattern for init (example from Apple's Cocoa
Memory Management Programming guide):
- (id)init {
if ((self = [super init])) {// superclass may return nil
// your initialization code goes here
}
return self;
}
So the init method below would look like this (pick your own favorite
brace placement):
- (id) init
{
if ( self=[super init] )
{
if ( LC( LC_ThreadState) )
NSLog( @"ControlMethods2 init for %@",self );
C=[self CM_CD_alloc_init];
[C retain];
}
return self;
}
Later,
Jeff
On Mar 8, 2007, at 6:35 PM, j o a r wrote:
On 8 mar 2007, at 23.05, David Carlisle wrote:
- (id) init {
[super init];
if (LC(LC_ThreadState)) NSLog(@"ControlMethods2 init for %@", self);
C = [self CM_CD_alloc_init];
[C retain];
return self;
}
For kicks, have you checked the return value of the call to [super
init] at the same time as you see the erroneous logs?
Could you try to add extra warnings and verify that you can build a
"release" build (ie. using optimizations) without any significant
warnings? Something like this:
WARNING_CFLAGS = -Wall -Wextra -Winit-self
Also note that it seems likely that you have a memory leak in the
code above. If you have a method that returns an object created via
a call to [[Foo alloc] init] it's _very_ unlikely that the receiver
should call retain on that object. I would say that the error is
not that you call retain there, but rather that it's _very_ unusual
for methods to return objects "with a positive retain count" like
that. They would typically be autoreleased, or something to that
same effect. See the memory management documentation for further
details and discussions.
Other than that, I can't see anything immediately suspicious in the
code that you provided.
Without more information it's difficult to say more, but my guess
would be that this is a memory management error + race condition.
It's likely that using log statements and NSZombieEnabled
significantly impacts your ability to reproduce this problem, as
they affect memory management and timings.
Create a copy of your project and try to reduce the amount of code
required to reproduce the problem as much as possible, to narrow
down the places you need to look for errors. Work on removing all
compiler warnings. Use ObjectAlloc and the "leaks" command line
tool to locate all memory leaks, and then fix them.
j o a r
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
40earthlink.net
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden