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 <jbmaxw...@rubato-music.com> 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
jbmaxw...@rubato-music.com
jbmax...@sfu.ca
_______________________________________________
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 arch...@mail-archive.com
