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.