Crash on _unload_image(); list of ObjC subclasses appears corrupted
Crash on _unload_image(); list of ObjC subclasses appears corrupted
- Subject: Crash on _unload_image(); list of ObjC subclasses appears corrupted
- From: Matthew Mott <email@hidden>
- Date: Thu, 19 Nov 2009 12:50:07 +0000
Hello,
We are writing a plugin for a 64-bit Mac host application which is loaded and
unloaded dynamically. The plugin is written in C and C++ and statically linked
against Qt 4.5 on 64-bit Mac OS. We do not use any Objective-C ourselves,
however the 4.5 version of Qt may use them internally in order to support
Cocoa.
Although our plugin loads and runs without problems, at application shutdown
the following crash is encountered in the Objective C runtime:
#0 0x00007fff846d631a in removeSubclass (supercls=0x7fff7070c200,
subcls=0x124dfeca0) at runtime/objc-runtime-new.m:870
#1 0x00007fff846d8067 in _unload_image (hi=0x12223a710) at runtime/objc-
runtime-new.m:1722
#2 0x00007fff846cd418 in _objc_unmap_image (hi=0x12223a710) at runtime/objc-
runtime.m:962
#3 0x00007fff846cd305 in unmap_image (mh=0x12356e000,
vmaddr_slide=4887863296) at runtime/objc-runtime.m:920
#4 0x00007fff5fc02b67 in __dyld__ZN4dyld11removeImageEP11ImageLoader ()
#5 0x00007fff5fc02d6f in __dyld__ZN4dyld20garbageCollectImagesEv ()
#6 0x00007fff5fc0ac56 in __dyld_dlclose ()
#7 0x00007fff80059755 in dlclose ()
#8 0x00007fff8413ad09 in _CFBundleDlfcnUnload ()
#9 0x00007fff8413cec9 in CFBundleUnloadExecutable ()
...
The line of code which is crashing is 870 (runtime/objc-runtime-new.m:870) in
the following listing:
865 OBJC_CHECK_LOCKED(&runtimeLock);
866 assert(getSuperclass(subcls) == supercls);
867
868 class_t **cp;
869 for (cp = &supercls->data->firstSubclass;
870 *cp && *cp != subcls;
871 cp = &(*cp)->data->nextSiblingClass)
872 ;
873 assert(*cp == subcls);
874 *cp = subcls->data->nextSiblingClass;
By tracing through execution we have identified that the problem occurs when
the variable cp points to an invalid location, which is caused by the
nextSiblingClass pointer in 871 being invalid.
Although it is quite possible that this is a Qt-related problem (the specific
class which is being removed is a QCocoaWindowDelegate), it would be helpful
for us to know more about the construction of this linked list of sibling
classes. Who or what is responsible for populating this list at application
startup (or elsewhere)? Are there any known situations in which the linked
list might be, or become, invalid?
Many thanks for any advice,
Matthew
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden