5

所以我最近开始研究一个大型软件项目，它使用 llvm-gcc 编译器在 OSX 上链接了几个静态和动态库。

我对 stl 有严重的问题。具体来说，非常简单的代码会崩溃。例如，在我的主项目中，以下代码会崩溃：

{
    std::vector< unsigned int > testvec;
    testvec.resize( 1 );
    testvec[0] = 0;
}

退出范围时，它会在 std::vector< unsigned int > 析构函数内部崩溃，抛出一个 SIGABRT 并说尚未分配正在释放的内存。具体来说：

malloc: *** error for object 0x135e8fc30: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

这只发生在发布版本中 - 调试版本工作得很好。

我最好的猜测是，其中一个外部库与另一个使用不同内部存储器布局的 STL 版本相关联，因此它试图释放大小或类似的东西。

我已经在我链接的所有库上运行了 nm，其中一些库具有外部 stl 符号（具体来说，std::vector< unsigned int > 析构函数在 nm 输出中用 S 标记）。但我不知道哪一个是罪魁祸首。

有没有办法检查 .a 或 dylib 文件以追踪哪些文件链接到不同版本的 STL？

[编辑]

这看起来像是两个静态库，两个不同的向量实现中描述的情况的真实示例，链接器会做什么？ 事实证明，链接器做了可怕、可怕的事情.. :)

4

1 回答 1

2

我相信otool -L这就是你要找的。这将列出程序使用的共享库。

您还应该检查您的包含路径。这似乎不太可能，但可能#include <vector>会引入非标准包含，其定义与标准库中的定义不匹配。

于 2012-04-04T04:43:13.200 回答