Thu 25 Mar 2010 11:29:28 PM UTC, original submission:
This only occurs when creating a lock for the second instance of our class, after the first instance has been deallocated.
Here's a backtrace that shows where it dies (stepping through code in sync.m):
78 class_addMethod(lockClass, @selector(dealloc), (IMP)deallocLockClass, types);
(gdb) n
80 if (!class_isMetaClass(obj->isa))
(gdb)
82 objc_registerClassPair(lockClass);
(gdb)
Program received signal SIGSEGV, Segmentation fault.
0x67844a2a in objc-1!__objc_resolve_class_links () from c:\GNUstep\GNUstep\System\Tools\objc-1.dll
(gdb) bt
#0 0x67844a2a in objc-1!__objc_resolve_class_links ()
from c:\GNUstep\GNUstep\System\Tools\objc-1.dll
#1 0x65ac71f5 in objc_registerClassPair (cls=0x9dad9b0) at runtime.c:1002
#2 0x65ac7c7c in initLockObject (obj=0x99cbad0) at sync.m:82
#3 0x65ac7d9e in objc_sync_enter (obj=0x99cbad0) at sync.m:124
#4 0x00476425 in -[VNCConnection setStatusString:] (self=0x99cbad0, _cmd=0x54e6b0,
aString=0x9b7e610) at VNCConnection.m:4449
I've committed a temporary fix for this, that simply removes the call to objc_disposeClassPair() in the deallocLockClass() function. Apparently the runtime can't handle disposing of a class and then creating a new class with the same superclass as the one that went away. I don't know if this is a Windows-specific problem or if it is an issue on Linux as well.
David, I understand from talking to Greg that you're the one who knows this stuff. If you have any questions about what's going on, give Greg a call.
|