Re: Exception catching problem since 10.4.3 using gcc 3.3 - IOKit. same kind of problem : crash after upgrading to QuickTime 704
Re: Exception catching problem since 10.4.3 using gcc 3.3 - IOKit. same kind of problem : crash after upgrading to QuickTime 704
- Subject: Re: Exception catching problem since 10.4.3 using gcc 3.3 - IOKit. same kind of problem : crash after upgrading to QuickTime 704
- From: Ananda Tallur <email@hidden>
- Date: Wed, 22 Feb 2006 17:13:42 +0100
Hi Martin,
I wanted to thank you once again for this further insight.
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 :
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0xfffffff4
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).
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:
[]
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:
__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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden