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 21:22:02 -0700
Poking around some more...
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. The code that fills this array, is this:
- (void) addCoincidenceToBeliefMemory:(int)coincidence
{
if(coincidence == 0)
return;
int memDepth = [[self sequencer] memoryDepth] - 1;
NSMutableArray* beliefMem = [self beliefMemory];
NSNumber* memCoinc = [[NSNumber alloc] initWithInt:coincidence];
[beliefMem insertObject:memCoinc atIndex:0];
UInt memCount = [beliefMem count];
if(memCount > memDepth)
[beliefMem removeLastObject];
[memCoinc release];
}
It's set up as a stack, so I can just grab the latest number from index 0. I know the memDepth, is **always** 5, because this is set elsewhere, and is never changed -- it's accessed by [[self sequencer] memoryDepth]. But I'm looking at the array right now, and it has 7 objects in it. How is that even possible?
Getting very confused... Help appreciated.
J.
On 2010-05-01, at 8:42 PM, James Maxwell wrote:
> ugh... okay, so changing the logic cured the crashes, but also negatively impacted the system (it's a machine-learning thing, and the old logic was crucial to the predictive power of the system).
> So, I'm back to the crash.
>
> So, looking more closely at the NSArray itself in the debugger, the items in the array come up as
>
> 0 NSCFNumber*
> 1 NSCFNumber*
> 2 NSObject*
> 3 _NSZombie_CFNumber*
> 4 NSObject*
>
> I have to confess, I have no idea why they aren't all NSCFNumbers, as that's all I'm putting in the array.
> In particular, I'm curious about the _NSZombie one, as I'm assuming that's the one that's probably causing the problems, yes?
>
> help!
>
> J.
>
>
> On 2010-05-01, at 7:19 PM, James Maxwell wrote:
>
>> 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
>
> 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