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 19:19:22 -0700
just to call off the dogs, in case there are any, I solved the crash by re-working the logic a little.
It's cleaner the new way anyway, though I don't know whether the concurrency stuff is really fixed
(or whether it was "really" broken!)
It works, and I'm a tight deadline, so that's all that matters!
J.
On 2010-05-01, at 5:54 PM, James Maxwell wrote:
> Okay, so let me give a little more info.
>
> Here's the stack trace.
>
> #0 0x7fff8578693c in __CFTypeCollectionRelease
> #1 0x7fff85783e43 in __CFArrayReleaseValues
> #2 0x7fff85764bc8 in _CFArrayReplaceValues
> #3 0x1000183ad in -[HSMM_Node addCoincidenceToBeliefMemory:] at HSMM_Node.m:229
> #4 0x100017803 in -[HSMM_Node topDown:] at HSMM_Node.m:121
> #5 0x100012a94 in __-[HSMM_NetworkController runNetworkOnInput:]_block_invoke_555 at HSMM_NetworkController.m:225
> #6 0x7fff804f3e68 in _dispatch_apply2
> #7 0x7fff804eb487 in dispatch_apply_f
> #8 0x10001232e in -[HSMM_NetworkController runNetworkOnInput:] at HSMM_NetworkController.m:218
> #9 0x100005050 in __-[OSC_Controller receivedOSCMessage:]_block_invoke_876 at OSC_Controller.m:252
> #10 0x7fff804a1e63 in dispatch_sync_f
> #11 0x100004155 in -[OSC_Controller receivedOSCMessage:] at OSC_Controller.m:251
> #12 0x10008a2bc in -[OSCManager receivedOSCMessage:] at OSCManager.m:232
> #13 0x10008af82 in -[OSCInPort handleScratchArray:] at OSCInPort.m:262
> #14 0x10008bc5f in -[OSCInPort OSCThreadProc] at OSCInPort.m:240
> #15 0x100054797 in -[VVThreadLoop threadCallback] at VVThreadLoop.m:76
> #16 0x7fff81943e99 in __NSThread__main__
> #17 0x7fff804a5f8e in _pthread_start
> #18 0x7fff804a5e41 in thread_start
>
> And the source for the method does does all the work is below. This wraps everything up in a couple of blocks.
> The second loop is the one that's causing the crash and the only way I think this could happen would be if the
> first loop hadn't completed. My, possibly totally misinformed, opinion was that this method would run the
> first loop to completion, then run the second. That is, all "aNode" objects would do their thing in the first loop
> **before** the second loop could start. But maybe I'm wrong about that. I have to admit that my grasp
> of GCD is pretty sketchy. If this isn't the case, and the second loop could, in fact, start running before all
> the aNode objects in the first loop had finished their processing, then I can totally understand why it would
> crash. Is there some way to ensure that? How would I make sure that *everything* started in the first
> loop finished before moving on to the second. If I do that, then my crash should be solved.
>
> - (void) runNetworkOnInput:(float *)inputPattern
> {
> printf("\n\n********* Start Run ************\n\n");
> int i, numLevels;
> numLevels = [[[self network] hierarchy] count];
>
> dispatch_queue_t hsmm_queue;
> hsmm_queue = dispatch_get_global_queue(0, 0);
>
> [self setPlaybackPossible:YES];
>
> for(i=0;i < numLevels;i++) // run up the network
> {
> NSMutableArray* level = [[[self network] hierarchy] objectAtIndex:i];
> dispatch_apply([level count],
> hsmm_queue,
> ^(size_t index) {
> HSMM_Node* aNode = [level objectAtIndex:index];
> [aNode setIsPassive:NO];
> if([aNode nodeLevel] == 1)
> {
> [aNode setPredictionRequestsLocked:NO];
> [aNode setInputCounter:([aNode inputCounter] + 1)];
> [aNode run:nil];
> } else {
> BOOL readyToLearn = YES;
> for(HSMM_Node* child in [aNode childNodes])
> {
> if([child nodeLevel] == 1 && [[child sequencer] predictionAccuracy] < 0.3)
> {
> readyToLearn = NO;
> break;
> }
> }
> if(readyToLearn == YES && [aNode predictionRequestsLocked] == YES) // the child is asking for help! the parent needs to learn
> {
> [aNode setPredictionRequestsLocked:NO];
> [aNode setInputCounter:([aNode inputCounter] + 1)];
> [aNode run:nil];
> }
> }
> });
> }
>
> 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];
> });
> }
> }
>
>
> On 2010-05-01, at 5:17 PM, Kyle Sluder wrote:
>
>> On May 1, 2010, at 5:04 PM, James Maxwell <email@hidden> wrote:
>>
>>> I'm having a crash when trying to remove the last item in an NSMutableArray.
>>> The app is a pretty complex system, and runs its two main processes in consecutively executed blocks.
>>> The blocks are run using dispatch_apply, on the global queue. The operation that's trying to
>>> access the NSArray is, I think, within the first block... but honestly, I can't be totally sure, as
>>> I don't know exactly why the app is crashing.
>>
>> Yes you do. You have a debugger and a stack trace.
>>
>>> I guess what I'm wondering is whether there's some fool-proof way of protecting that NSArray from being read and changed simultaneously?
>>> I tried making the array nonatomic, but that didn't solve the problem.
>>> Of note is the fact that this is directly related to processing load, so I'm assuming it has to do
>>> with some timing thing -- as the app gets more loaded down, things get sketchy.
>>
>> The concept you're looking for is thread safety. It is, in general, a Very Hard Problem.
>>
>>
>>> I know this isn't a great description of the problem, but hopefully someone has some thoughts to share.
>>
>> If you have a crash, the only two useful pieces of information are the source code and the stack trace. Anything else risks misinterpretation and therefore wasted time.
>>
>> --Kyle Sluder
>
> James B Maxwell
> Composer/Doctoral Student
> School for the Contemporary Arts (SCA)
> School for Interactive Arts + Technology (SIAT)
> Simon Fraser University
> email@hidden
> email@hidden
>
> _______________________________________________
>
> 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
James B Maxwell
Composer/Doctoral Student
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
email@hidden
email@hidden
_______________________________________________
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