site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Nov 19, 2009, at 4:50 AM, Matthew Mott wrote:

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.

Objective-C code that is intended to be unloaded must be written very carefully. It's likely that Qt is not written that way. Beware. You can set environment variable OBJC_DEBUG_UNLOAD=YES to get some warnings about poorly-behaved unloadable code.

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?

firstSubclass and nextSiblingClass together form a tree of classes. Any class that is "used" is added to that tree when realizeClass() calls addSubclass(). I don't know of any reason for that tree to be invalid other than garden-variety memory smashers. -- Greg Parker gparker@apple.com Runtime Wrangler _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com