site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Hi Martin, I wanted to thank you once again for this further insight. Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xfffffff4 The problem occurs when : -> compiling with gcc3.3, -> linking against QuickTime, directly or indirectly -> linking using flat_namespace mode Problem can be solved : -> by adding option -single_module at link time Hope this can help someone. Regards Anand On 4 janv. 06, at 01:50, Martin Costabel wrote: Martin Costabel wrote: [] __Unwind_GetIP __Unwind_GetLanguageSpecificData __Unwind_GetRegionStart These come from the module eh_personality.o from libstdc++.a. -- Martin _______________________________________________ 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... Also, this -single_module option has also enabled us recently to solve the same kind problem, but this time, due to QuickTime 7.0.4 upgrade. QuickTime 7.0.4 is dynamically linked against several gcc4 runtime dynamic libraries, as show the following command : otool -L /System/Library/Frameworks/QuickTime.framework/Versions/A/ QuickTime Here is the result : QuickTime: /System/Library/Frameworks/QuickTime.framework/Versions/A/ QuickTime (compatibility version 1.0.0, current version 63.0.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/ CoreServices (compatibility version 1.0.0, current version 18.0.0) /System/Library/Frameworks/Carbon.framework/Versions/A/ Carbon (compatibility version 2.0.0, current version 128.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/ A/CoreFoundation (compatibility version 150.0.0, current version 368.26.0) /System/Library/Frameworks/CoreAudio.framework/Versions/A/ CoreAudio (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/AudioToolbox.framework/Versions/A/ AudioToolbox (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/AudioUnit.framework/Versions/A/ AudioUnit (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/Accelerate.framework/Versions/A/ Accelerate (compatibility version 1.0.0, current version 4.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/ApplicationServices (compatibility version 1.0.0, current version 22.0.0) /System/Library/Frameworks/Security.framework/Versions/A/ Security (compatibility version 1.0.0, current version 24989.0.0) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) /System/Library/Frameworks/SystemConfiguration.framework/ Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.2) As you can see, QuickTime is now linked dynamically against : /usr/ lib/libstdc++.6.dylib, and /usr/lib/libgcc_s.1.dylib, which are components of C++ runtime library coming with gcc4. This time, the problem caused by this mix up was a crash (KERN_INVALID_ACCESS), when using QString objects (Trolltech Qt strings) : Below is an excerpt of the backtrace we had : Thread 0 Crashed: 0 libstdc++.6.dylib 0x955733bc std::basic_ostream<char, std::char_traits<char> >::sentry::sentry[in-charge] (std::basic_ostream<char, std::char_traits<char> >&) + 40 1 libstdc++.6.dylib 0x95575a98 std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> > (std::basic_ostream<char, std::char_traits<char> >&, char const*) + 40 It clearly show that gcc4 libstdc++.6.dylib is being used, whereas the application is compiled with gcc3.3. libstdc++.6.dylib gets loaded because of QuickTime (7.0.4), and QuickTime is loaded because of Qt (Trolltech). time and DYLD_PRINT_LIBRARIES and DYLD_PRINT_BINDINGS at run time. What I observed makes me believe that the crucial variable is __Unwind_RaiseException To be complete for the record: There are a couple of other symbols behaving in the same way: This email sent to site_archiver@lists.apple.com