Re: crash on altering NSMutableArray
Re: crash on altering NSMutableArray
- Subject: Re: crash on altering NSMutableArray
- From: James Maxwell <email@hidden>
- Date: Sat, 1 May 2010 22:50:24 -0700
>>
>
> This strongly suggests a memory management problem -- something is over-releasing the items in the array.
>
okay, this is what I figured, but I can't see anywhere where this could be happening.
> On May 1, 2010, at 21:22, James Maxwell wrote:
>
>> If I drop into the debugger arbitrarily, before the crash, and check this same array, I noticed that it is nicely filled with NSCFNumbers. But, strangely, there are too many.
>
> My guess is that you've still got multiple threads accessing the mutable array simultaneously, and that's not thread-safe if one of the accesses is changing the array.
Well, there's only one object that "changes" the array, so I don't know how this could happen.
I would like to know, though, whether this:
for(i=numLevels - 1;i >= 0;--i) // run back down the network
{
NSMutableArray* level = [[[self network] hierarchy] objectAtIndex:i];
dispatch_apply([level count],
hsmm_queue,
^(size_t index) {
HSMM_Node* aNode;
aNode = [level objectAtIndex:index];
[aNode getEvidenceFromParents];
[aNode topDown:[aNode parentEvidence]];
if([aNode nodeLevel] == 1)
[[aNode sequencer] predictForward:NO];
});
}
will process all of the "aNode" objects on the current "level", before moving on to the next "level"?
My intention with the above code is to process each level in parallel, but to finish processing a level before moving to the next level. If this is not the proper way to do that, I'd really appreciate any help in correcting this code.
thanks,
J.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden