Re: PropertyLocks?: strange exc_bad_access crash
Re: PropertyLocks?: strange exc_bad_access crash
- Subject: Re: PropertyLocks?: strange exc_bad_access crash
- From: James Maxwell <email@hidden>
- Date: Mon, 9 Aug 2010 11:48:36 -0700
Sorry, no, the initWithCoder happens at program launch, in the main thread - nothing fancy there.
It's just this method (the crashing one) that's running in its own thread, and this is the same when creating the data structure from scratch (i.e. in init), where it doesn't crash.
Also, the inputMemory array isn't actually decoded - I only need it at runtime, so it's just inited manually in initWithCoder.
- (id) initWithCoder:(NSCoder *)aDecoder
{
if(self = [super init])
{
[self setHsmmNode_s:[aDecoder decodeObjectForKey:@"hsmmNode_s"]];
[self setMaxSeqs:[aDecoder decodeIntForKey:@"maxSeqs"]];
[self setMaxSeqLength:[aDecoder decodeIntForKey:@"maxSeqLength"]];
[self setTimeScale:[aDecoder decodeIntForKey:@"timeScale"]];
[self setLZTree:[aDecoder decodeObjectForKey:@"LZTree"]];
NSMutableArray* mem = [[NSMutableArray alloc] init];
[self setInputMemory:mem];
[mem release];
[self setDefaults];
}
return self;
}
This is from HSMM_Sequencer's initWithCoder, where the accessor for inputMemory synthesized and retaining.
As a detail, when the program crashes, and drops into the debugger, clicking on line #2 of the trace (below) doesn't actually take me to the line in the code where inputMemory is accessed. It just takes me to the end of HSMM_Sequencer's implementation section. I'm guessing the memory's banjaxed enough that it just doesn't know where to put me, but maybe that's significant?
J.
On 2010-08-09, at 11:03 AM, Quincey Morris wrote:
> On Aug 9, 2010, at 10:07, James Maxwell wrote:
>
>> I'm getting a crash with this trace:
>>
>> #0 0x99535ed7 in objc_msgSend
>> #1 0xa0bf5224 in PropertyLocks
>> #2 0x0001b792 in -[HSMM_Sequencer inputMemory] at HSMM_Sequencer.m:664
>> #3 0x0001903b in -[HSMM_Sequencer predictForward:] at HSMM_Sequencer.m:262
>> #4 0x00010253 in __-[HSMM_NetworkController runNetworkPrediction]_block_invoke_ at HSMM_NetworkController.m:256
>> #5 0x97762aa0 in _dispatch_apply2
>> #6 0x976332b2 in _dispatch_worker_thread2
>> #7 0x97632d41 in _pthread_wqthread
>> #8 0x97632b86 in start_wqthread
>>
>>
>> It only happens when running a particular function from its saved state (i.e., from initWithCoder). I've looked for the usual suspects, in terms of zombies and such, but I can't see anything obvious. The same algorithm runs fine from its newly created state (i.e., using init, rather than initWithCoder), so decoding must be somehow involved.
>> Does this trace indicate anything special? Snooping into the objc_msgSend in gdb I see that the selector is a retain, which I'm assuming would only cause a crash if it was sent to a released object. I've not been able to find any info on "PropertyLocks", but it certainly sounds as though it's related to locking atomic properties... don't know though. What's strange, to me, is that if this is a threading problem, why does it only happen from a decoded state, not from a clean inited state?
>
> Where is initWithCoder? Are you saying that you spun off a background thread that uses just-decoded objects from within initWithCoder in a different thread? In that case, how do you ensure that the decoding is complete first?
>
> Unless you do something special, the original decoding path is going to continue in parallel with the background operation. That means a mutable and possibly changing object graph is actively being used by 2 threads, which could be a recipe for disaster, even if only one of the threads is changing anything. It could even mean that the decoding itself proceeds simultaneously in multiple threads, which is likely an even bigger disaster.
>
> Or your problem could easily be a memory management error, as Graham suggests, but the conjunction of initWithCoder: and multithreading set off very loud alarm bells in my head.
>
>
> _______________________________________________
>
> 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