[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
Delivered-to: email@hidden
Delivered-to: email@hidden

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:
http://lists.apple.com/mailman/options/xcode-users/email@hidden

This email sent to email@hidden

Follow-Ups:
- Re: Using a GCC 3.3-built C++ loadable bundle in a GCC 4-built app
  - From: Arne Scheffler <email@hidden>

Prev by Date: Re: javadoc for xcode
Next by Date: Re: GCC 4 and strict aliasing
Previous by thread: Re: UB issue -- include order?
Next by thread: Re: Using a GCC 3.3-built C++ loadable bundle in a GCC 4-built app
Index(es):
- Date
- Thread

Home