我正在尝试使用Linux上的应用程序调试问题。在libstdc++.so或libstdc.so的随机位置，它会随着SIGSEGV而崩溃。
在任何地方似乎都没有明显的竞争条件，因为我添加的帖子中的工作非常孤立。但它几乎一直都在崩溃。
应用程序使用g++ -c ... -pthread -D_REENTRANT进行编译，并与g++ -pthread -o ...
但它仍然在libstdc*.so函数之一中几乎一直崩溃。我浪费了几天时间试图弄清楚什么是错的，但是没有去......
有没有人有任何提示？有没有办法确保libstdc*.so被编译为线程感知？任何可以帮助我的gdb命令？调试堆？
我在Linux上工作了几年，所以我迷失了......
答案 0 :(得分：4)
你应该做的事情很少：
编写单元测试。虽然它们对查找线程问题没有多大帮助，但它们可以帮助您找到错误的内存访问问题。
答案 1 :(得分：4)
在编译时尝试使用-g（如果您还没有），以获取符号调试器信息。
你得到一个核心倾销？如果是这样，您可以使用gdb加载可执行文件的核心，如下所示：
gdb <my-exe> <my-core-file>
加载后（假设您使用-g编译），您可以使用info threads获取所有线程堆栈的列表，并查看导致问题的线程。如果您遵循导致seg错误的堆栈跟踪从libstdc++.so或libstdc.so进行备份，则应该明显地知道发生了什么。至少它会让你到达正确的区域。
如果你没有获得核心，你可以在调试器本身内运行你的应用程序吗？
这种技术对于解决线程死锁问题非常有用：只需使用以下命令附加到进程：
gdb <my-exe> <my-process-id>
并查找相互锁定的两个线程。