Summary: The Python module is associated with a different version of libstdc++.dylib than the Python executable. As a result, iostream calls from a module failure.
Background
I am creating a Python module using SWIG on an older computer (running 10.5.8). For various reasons, I use GCC 4.5 (installed via MacPorts) to do this using Python 2.7 (installed via MacPorts, compiled using the system GCC 4.0.1).
Observed behavior
In short: calling str( myObject ) in Python causes C ++ code to call std::operator<< <std::char_traits<char> > . This causes the following error:
Python(487) malloc: *** error for object 0x69548c: Non-aligned pointer being freed *** set a breakpoint in malloc_error_break to debug
Setting a breakpoint and calling backtrace if it is absent gives:
#0 0x9734de68 in malloc_error_break () #1 0x97348ad0 in szone_error () #2 0x97e6fdfc in std::string::_Rep::_M_destroy () #3 0x97e71388 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string () #4 0x97e6b748 in std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::overflow () #5 0x97e6e7a0 in std::basic_streambuf<char, std::char_traits<char> >::xsputn () #6 0x00641638 in std::__ostream_insert<char, std::char_traits<char> > () #7 0x006418d0 in std::operator<< <std::char_traits<char> > () #8 0x01083058 in meshLib::operator<< <tranSupport::Dimension<(unsigned short)1> > ( os=@0xbfffc628 , c=@0x5a3c50 ) at /Users/sethrj/_code/pytrt/meshlib/oned/Cell.cpp:21 #9 0x01008b14 in meshLib_Cell_Sl_tranSupport_Dimension_Sl_1u_Sg__Sg____str__ (self=0x5a3c50) at /Users/sethrj/_code/_build/pytrt-gcc45DEBUG/meshlib/swig/mesh_onedPYTHON_wrap.cxx:4439 #10 0x0101d150 in _wrap_Cell_T___str__ (args=0x17eb470) at /Users/sethrj/_code/_build/pytrt-gcc45DEBUG/meshlib/swig/mesh_onedPYTHON_wrap.cxx:8341 #11 0x002f2350 in PyEval_EvalFrameEx () #12 0x002f4bb4 in PyEval_EvalCodeEx () [snip]
Alleged problem
I believe the problem is that my code is referencing the new version of libstdC ++:
/opt/local/lib/gcc45/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.14.0)
whereas the Python binary has a very indirect dependency on the libstdc++ system, which first loads (output from info shared to gdb):
1 dyld - 0x8fe00000 dyld YY /usr/lib/dyld at 0x8fe00000 (offset 0x0) with prefix "__dyld_" 2 Python - 0x1000 exec YY /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python (offset 0x0) (objfile is) /opt/local/bin/python 3 Python F 0x219000 dyld YY /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Python at 0x219000 (offset 0x219000) 4 libSystem.B.dylib - 0x9723d000 dyld YY /usr/lib/libSystem.B.dylib at 0x9723d000 (offset -0x68dc3000) (commpage objfile is) /usr/lib/libSystem.B.dylib[LC_SEGMENT.__DATA.__commpage] 5 CoreFoundation F 0x970b3000 dyld YY /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation at 0x970b3000 (offset -0x68f4d000) 6 libgcc_s.1.dylib - 0x923e6000 dyld YY /usr/lib/libgcc_s.1.dylib at 0x923e6000 (offset -0x6dc1a000) 7 libmathCommon.A.dylib - 0x94af5000 dyld YY /usr/lib/system/libmathCommon.A.dylib at 0x94af5000 (offset -0x6b50b000) 8 libicucore.A.dylib - 0x97cf4000 dyld YY /usr/lib/libicucore.A.dylib at 0x97cf4000 (offset -0x6830c000) 9 libobjc.A.dylib - 0x926f0000 dyld YY /usr/lib/libobjc.A.dylib at 0x926f0000 (offset -0x6d910000) (commpage objfile is) /usr/lib/libobjc.A.dylib[LC_SEGMENT.__DATA.__commpage] 10 libauto.dylib - 0x95eac000 dyld YY /usr/lib/libauto.dylib at 0x95eac000 (offset -0x6a154000) 11 libstdc++.6.0.4.dylib - 0x97e3d000 dyld YY /usr/lib/libstdc++.6.0.4.dylib at 0x97e3d000 (offset -0x681c3000) 12 _mesh_oned.so - 0x1000000 dyld YY /Users/sethrj/_code/_build/pytrt-gcc45DEBUG/meshlib/swig/_mesh_oned.so at 0x1000000 (offset 0x1000000) 13 libhdf5.7.dylib - 0x122c000 dyld YY /opt/local/lib/libhdf5.7.dylib at 0x122c000 (offset 0x122c000) 14 libz.1.2.5.dylib - 0x133000 dyld YY /opt/local/lib/libz.1.2.5.dylib at 0x133000 (offset 0x133000) 15 libstdc++.6.dylib - 0x600000 dyld YY /opt/local/lib/gcc45/libstdc++.6.dylib at 0x600000 (offset 0x600000) [snip]
Note that the malloc error occurs in the memory address for the libstdc++ system, and not the one with which the shared library is associated.
Attempt to resolve
I tried to get MacPorts to create Python using GCC 4.5 rather than the Apple compiler, but the installation phase does not work because it needs to create a “Framework” for the Mac, which apparently does not have vanilla GCC.
Even with the -static-libstdc++ flag of the __ostream_insert compiler, it calls std::basic_streambuf from the system-loaded shared library.
I tried changing DYLD_LIBRARY_PATH by adding /opt/local/lib/gcc45/ , but to no avail.
What can I do to make this work? I am at my end.
Additional Information
This problem seems to be common for mac os x . Please note that on all debugging pins, an address is displayed that goes between calls to std::__ostream_insert and std::basic_streambuf::xsputn : it leaves the new GCC 4.5 code and goes to the old shared library code in /usr/bin . Now, to find a workaround ...