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 20:42:42 -0700
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