我正在尝试调试 Linux 上的应用程序问题。它倾向于在libstdc++.so或的随机位置与 SIGSEGV 一起崩溃libstdc.so。
似乎在任何地方都没有明显的竞争条件，因为我添加的线程中的工作非常孤立。但它仍然几乎一直崩溃。
应用程序用 编译g++ -c ... -pthread -D_REENTRANT，并用 链接g++ -pthread -o ...
但它仍然几乎一直在其中一个libstdc*.so功能中崩溃。我浪费了几天时间试图找出问题所在，但没有去...
有没有人有任何提示？有没有办法确保libstdc*.so编译为线程感知？任何可以帮助我的 gdb 命令？调试堆？
我只在 Linux 上工作了几年，所以我迷路了……
您应该做几件事：
编写单元测试。尽管它们在查找线程问题方面没有多大帮助，但它们可以极大地帮助您查找错误的内存访问问题。
-g如果您还没有编译，请尝试在编译时使用，以获取符号调试器信息。
你得到一个核心转储？如果是这样，您可以使用gdb以下方式针对可执行文件加载核心：
gdb <my-exe> <my-core-file>
加载后（假设您使用 编译-g），您可以使用info threads获取所有线程堆栈的列表并查看导致问题的线程。如果您跟踪导致段错误的堆栈跟踪，libstdc++.so或者libstdc.so它应该很明显发生了什么。至少它会让你到达正确的区域。
如果您没有获得核心，您可以在调试器本身内运行您的应用程序吗？
这种技术对于深入了解线程死锁也非常有用：只需使用以下方法附加到进程：
gdb <my-exe> <my-process-id>
并寻找相互锁定的两个线程。