discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems with GSLazyRecursiveLock on MOSX


From: David Ayers
Subject: Re: Problems with GSLazyRecursiveLock on MOSX
Date: Thu, 22 Apr 2004 10:02:27 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113

Philip Mötteli wrote:
Hi


I try to use GSW on MOSX. The moment I access the first page, there's some initializing stuff and then a GSLazyRecursiveLock gets deallocated, which in turn calls [super deallocate] and the super class crashes somewhere in pthread_mutex_destroy. I have the backtrace attached. The output from the program doesn't help me a lot:

[snip]

I think the backtrace could help more:

#0  0xffff8264 in __spin_lock ()
#1  0x90014058 in pthread_mutex_destroy ()
#2  0x90a22bdc in -[NSRecursiveLock dealloc] ()
#3 0x0021195c in -[ dealloc] (self=0x6d2690, _cmd=0x90870b34) at GSLock.m:228 #4 0x00211a64 in -[GSLazyRecursiveLock init] (self=0x6d2690, _cmd=0x9083ed94) at GSLock.m:241

Hmm. The application seems to be in a multi threaded state already, when +[GSRecursiveLazy newLockAt:] is being called for the first time. That's why we try to RELEASE(self) the new GSRecursiveLock and then we would replace self with a NSRecursiveLock. This is the recursive lock uses in GSCategories.m internally to guard newLockAt: calls. It's being setup during an +initialize so that it's done under the ObjC runtime's internal lock. It seems that Foundation's dealloc implementation of NSLock makes assumptions about the runtimes lock.

One solution could be changing Source/Additions/GSCategories.m _GSLockInitializer to initialize the local_lock with an NSRecursiveLock (this would make all calls to newLockAt: slower, but I'm not sure if that's significant). This would "work around" the problem by not creating a GSLazy*Lock during +initialize.

Another would be to change Source/Additions/GSLock.m [GSLazy(Recursive)Lock] to AUTORELEASE(self) instead of RELEASE(self). This could make GSLazy*Lock safe(r) wrt +initialize.

I'm leaning toward the latter but I'm open to suggestions.

Cheers,
David



#5 0x0020a038 in +[_GSLockInitializer initialize] (self=0x23778c, _cmd=0x9083ebbc) at GSCategories.m:1161
#6  0x908329e0 in class_initialize ()
#7  0x90831524 in _class_lookupMethodAndLoadCache ()
#8  0x90831298 in objc_msgSend ()
#9 0x0020a370 in newLockAt (self=0x23793c, _cmd=0x401428, location=0x402260) at GSCategories.m:1181 #10 0x0020a0cc in +[NSRecursiveLock(GSCategories) newLockAt:] (self=0x23793c, _cmd=0x401428, location=0x402260) at GSCategories.m:1254 #11 0x003f2568 in GSUseStrictWO451Compatibility (key=0x0) at EONSAddOns.m:71






reply via email to

[Prev in Thread] Current Thread [Next in Thread]