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 (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/jbmaxwell%40rubato-music.com
>
> This email sent to jbmaxw...@rubato-music.com
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
