执行摘要：Python模块与不同版本的libstdc++.dylib链接，而不是Python可执行文件。结果是从模块调用iostream崩溃。
我正在较旧的计算机上使用SWIG创建一个Python模块（运行10.5.8）。由于各种原因，我使用GCC 4.5（通过MacPorts安装）使用Python 2.7（通过MacPorts安装，使用系统默认的GCC 4.0.1编译）。
简而言之：在Python中调用str( myObject )会导致C ++代码依次调用std::operator<< <std::char_traits<char> >。这会产生以下错误：
Python(487) malloc: *** error for object 0x69548c: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
设置断点并在失败时调用backtrace给出：
#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]
我认为问题是我的代码链接到新版本的libstdc ++：
/opt/local/lib/gcc45/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.14.0)
而Python二进制文件非常间接依赖于系统libstdc++，它首先加载（在gdb中从info shared输出）：
1 dyld - 0x8fe00000 dyld Y Y /usr/lib/dyld at 0x8fe00000 (offset 0x0) with prefix "__dyld_"
2 Python - 0x1000 exec Y Y /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 Y Y /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Python at 0x219000 (offset 0x219000)
4 libSystem.B.dylib - 0x9723d000 dyld Y Y /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 Y Y /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation at 0x970b3000 (offset -0x68f4d000)
6 libgcc_s.1.dylib - 0x923e6000 dyld Y Y /usr/lib/libgcc_s.1.dylib at 0x923e6000 (offset -0x6dc1a000)
7 libmathCommon.A.dylib - 0x94af5000 dyld Y Y /usr/lib/system/libmathCommon.A.dylib at 0x94af5000 (offset -0x6b50b000)
8 libicucore.A.dylib - 0x97cf4000 dyld Y Y /usr/lib/libicucore.A.dylib at 0x97cf4000 (offset -0x6830c000)
9 libobjc.A.dylib - 0x926f0000 dyld Y Y /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 Y Y /usr/lib/libauto.dylib at 0x95eac000 (offset -0x6a154000)
11 libstdc++.6.0.4.dylib - 0x97e3d000 dyld Y Y /usr/lib/libstdc++.6.0.4.dylib at 0x97e3d000 (offset -0x681c3000)
12 _mesh_oned.so - 0x1000000 dyld Y Y /Users/sethrj/_code/_build/pytrt-gcc45DEBUG/meshlib/swig/_mesh_oned.so at 0x1000000 (offset 0x1000000)
13 libhdf5.7.dylib - 0x122c000 dyld Y Y /opt/local/lib/libhdf5.7.dylib at 0x122c000 (offset 0x122c000)
14 libz.1.2.5.dylib - 0x133000 dyld Y Y /opt/local/lib/libz.1.2.5.dylib at 0x133000 (offset 0x133000)
15 libstdc++.6.dylib - 0x600000 dyld Y Y /opt/local/lib/gcc45/libstdc++.6.dylib at 0x600000 (offset 0x600000)
[snip]
请注意，malloc错误发生在系统libstdc++的内存地址中，而不是共享库链接的内存地址。
我试图强制MacPorts使用GCC 4.5而不是Apple编译器构建Python，但安装阶段失败，因为它需要创建一个Mac“框架”，而vanilla GCC显然不会这样做。
即使使用-static-libstdc++编译器标志，__ void_insert也会从系统加载的共享库中调用std::basic_streambuf。
我尝试通过预先/opt/local/lib/gcc45/来修改DYLD_LIBRARY_PATH，但没有用。
我该怎么做才能让它发挥作用？我的智慧结束了。
此问题似乎是common to mac os x。请注意，在所有调试输出中，地址在std::__ostream_insert和std::basic_streambuf::xsputn的调用之间跳转：它将保留新的GCC 4.5代码并跳转到/usr/bin中的旧共享库代码。现在，找一个解决方法......
答案 0 :(得分：3)
解决了它。我发现在Mac上混合GCC版本时这个问题并不常见。阅读this solution for mpich并查看mpich source code后，我发现解决方案是在mac系统上向gcc添加以下标志：
-flat_namespace
我很开心。我希望这没有花一个星期的时间来搞清楚。 ：）
答案 1 :(得分：-3)
在GDB中运行Python，在malloc_error_break上设置断点。这将向您展示未被分配的被释放的内容。我怀疑这是libstdc ++版本之间的ABI之间的错误。