Re: Crash on _unload_image(); list of ObjC subclasses appears corrupted
Re: Crash on _unload_image(); list of ObjC subclasses appears corrupted
- Subject: Re: Crash on _unload_image(); list of ObjC subclasses appears corrupted
- From: Greg Parker <email@hidden>
- Date: Thu, 19 Nov 2009 10:55:09 -0800
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 email@hidden Runtime Wrangler
_______________________________________________
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