Thanks Greg. It was indeed a category issue but I seem to have fixed one problem and found another. If I load the first bundle, make a method call, then immediately unload, load the second bundle and make the same function call (all in the same event) I end up crashing when the autoreleas pool gets popped. If I do each in a separate event everything is fine. Am I right in assuming it is only the code that gets unloaded and no memory that has been initialised by methods in the bundle get freed when the bundle is unloaded i.e. is it safe for me to keep an NSDictionary around that has been passed back to me by a method in the bundle once it has been unloaded? (the dictionary contains only standard foundation kit objects). Also any other things to watch out for would be greatly appreciated.
On 27 Jan 2010, at 22:30, Greg Parker wrote: > On Jan 27, 2010, at 2:01 AM, Jonathan Guy wrote: >> This problem has me pretty stumped. I've been trying to figure this out for >> about a week now with no success. I have an embedded framework which itself >> has two embedded bundles. The two bundles contain the same code of an open >> source project but just different versions. The framework is designed to >> dynamically load and unload these bundles as required as only one can be >> loaded at any one time. The bundle project contains about 6 obj-c classes >> which link to the dylibs of the open source project (embedded in the >> bundle). If I only load one bundle the app is fine. If I load a bundle and >> then unload it the app becomes unstable and either eventually crashes or >> crashes on quit. The crash almost always seems to happen on the call >> "fixupSelectorsInMethodList". I have read all Apples docs on code loading >> (which seems out of date as they state that NSBundles can't be unloaded) and >> from that I've set the -fno-constant-cfstrings compiler flag, turned on >> garbage collection support and have no classes or pointers to any objects >> derived from code in the bundle. In fact if I just load the bundle and >> unload without actually doing anything the app still crashes on quit. I've >> run "Build and Analyze" on all components and everything check out. I've run >> the app with "Objects Allocations" and can't see anything out of place. It's >> starting to drive me nuts. > > Bundle unloading is fragile. There's a list of caveats a mile long, mostly of > the form "if your unloadable bundle does X then you may crash after it is > unloaded". > > If you're crashing in method list fixup, a likely problem is that the > unloadable bundle is adding categories to other classes outside the bundle. > Such categories are not cleaned up when the bundle is unloaded, and the app > may crash afterwards when that class is used again. > > The runtime can help find some unsafe bundles. Run the app with environment > variable OBJC_DEBUG_UNLOAD=YES. Then when a bundle is unloaded, it will look > for some unsafe things in the bundle (like categories on outside classes) and > complain in the console if it finds anything. (Note that OBJC_DEBUG_UNLOAD > currently only works in 32-bit.) > > > -- > Greg Parker gpar...@apple.com Runtime Wrangler > > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
