Using a GCC 3.3-built C++ loadable bundle in a GCC 4-built app
Using a GCC 3.3-built C++ loadable bundle in a GCC 4-built app
- Subject: Using a GCC 3.3-built C++ loadable bundle in a GCC 4-built app
- From: Jesper Papmehl <email@hidden>
- Date: Fri, 17 Mar 2006 21:37:32 +0100
Hi!
I have a loadable bundle that I build with GCC 3.3 (because it must
be useable back to Mac OS X 10.2). I then have an app built with GCC
4 that uses the loadable bundle. Both the bundle and the app use C++
exceptions, but exceptions are never thrown across the boundary
between the bundle and the app. Instead, error codes are used in the
interface to the loadable bundle.
I have problems with crashes inside
_dyld_get_image_containing_address (see below for backtrace) when
quitting my app. The crashing is due to a EXC_BAD_ACCESS signal.
It turns out that if I throw an exception inside the loadable bundle,
catch it and return it as an error code to the app, and then rethrow
it as an exception in the app code, my app will crash when quitting
(but not before then). If I only throw (and catch) inside the
loadable bundle, it doesn't crash. If I only throw in the app, it
doesn't crash. And finally, if I compile the loadable bundle with GCC
4, it doesn't crash.
I have verified that it isn't an exception-safety problem in the
bundle. I can get the problem by simply doing:
try {
throw std::exception();
}
catch (...) {
error = kSomeErrorCode;
}
return error;
in my bundle.
Is mixing loadable bundles compiled with GCC 3.3 and apps compiled
with GCC 4 supposed to work? Is there anything I can do to work
around this problem (and still maintain compatibility with 10.2 for
by bundle)?
TIA
/Jesper Papmehl
Propellerhead Software
Backtrace when the crash happens (in one particular app, it always is
inside _dyld_get_image_containing_address, but the path to that
function is different in different apps, but it is always due to some
bundle being unloaded (but never "my" loadable bundle):
#1 0x8fe033d0 in __dyld__ZN4dyld26findImageContainingAddressEPKv
#2 0x8fe0748c in __dyld__dyld_get_image_header_containing_address
#3 0x90001700 in _dyld_get_image_header_containing_address
#4 0x9005e238 in dwarf2_unwind_dyld_remove_image_hook
#5 0x8fe0212c in __dyld__ZN4dyld11removeImageEP11ImageLoader
#6 0x8fe08524 in __dyld_NSUnLinkModule
#7 0x9005e0e4 in NSUnLinkModule
#8 0x9079d348 in _CFBundleDYLDUnloadBundle
#9 0x90773c20 in CFBundleUnloadExecutable
#10 0x90773aa4 in __CFBundleDeallocate
#11 0x9073d554 in _CFRelease
#12 [code in my app that releases a bundle (which is completely
unrelated to the bundle I'm talking about above, and is not included
in other apps that exhibits the same problem)]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden