On Thu, Oct 30, 2008 at 6:04 PM, Jamie Johnson <[EMAIL PROTECTED]> wrote:
>
> Looks like you're hosing memory because the subsequent invocation operations
> are being released prior to their completion as seen in this call stack:
>
> #0 0x00001a0c in -[MyOp dealloc] at NSOp-Test.m:27
> #1 0x94fba20f in NSPopAutoreleasePool
> #2 0x9504f3a8 in -[NSOperation start]
> #3 0x00001ad6 in -[MyOp start] at NSOp-Test.m:39
>
> As a guess the NSOperationQueue places the operation in an autoreleasepool,
> not really retaining it itself. The nearest pool happens to be constructed
> in NSOperation -start. Upon exit boom!
It's a good theory. Alas, I don't think it's the case.
To prove this, take my original test case and replace the -test method
with this group of methods:
- (void)test
{
[NSThread detachNewThreadSelector:@selector(_enqueueThread)
toTarget:self withObject:nil];
}
- (void)_enqueueThread
{
while(1)
{
NSAutoreleasePool *pool = [NSAutoreleasePool new];
NSInvocationOperation *op = [[NSInvocationOperation alloc]
initWithTarget:self selector:@selector(_operationTarget) object:nil];
[_queue addOperation:op];
[op release];
[pool release];
}
}
- (void)_operationTarget
{
}
This avoids the pitfall you mention but still (on my computer) throws
the same exception as before.
Based on the state of the program when it crashes, it appears that the
problem is caused by a race condition which occasionally causes two of
the worker threads that NSOperationQueue spawns to dequeue and execute
the same NSOperation. Since an NSOperation is only supposed to run
once, things fall down go boom. This is just a theory, mind, and I'm
not sure of it yet.
Mike
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
