如何从这些信息中追踪错误代码答案

【问题标题】：How to trace the buggy code from this information如何从这些信息中追踪错误代码
【发布时间】：2014-10-21 10:04:40
【问题描述】：

我的项目很大而且是多线程的。应该有一个错误会导致整个程序崩溃。

对于发布版本，它有时会卡住，但不经常出现。对于调试代码，它更有可能出现。而gdb的堆栈跟踪如下。

0  clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:81
1  0x00007dff8270c700 in ?? ()
2  0x00007ffff6dde38d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

这些信息不足以让我找到错误代码。

所以我的问题是：如何从崩溃中获取更多信息？ gdb 或其他高级工具的任何高级用法？

=============更新==============

要补充一点，在打印出所有线程 ID 后，我找出了崩溃的线程。线程的唯一区别是它与 std 线程对象分离。如果有人有这方面的经验，请告诉我。

============= 更新2 ================

这个问题还没有解决，结果是一个严重的问题。如果我在终端中运行，它将使整个终端和当前在我的用户名下运行的所有其他程序崩溃。然后系统关闭，并且有一段时间无法通过 ssh 访问。还有一些其他用户的管道损坏了，看来我的程序使 sshd 没有响应。

过了一会儿我又能登录了，发现程序的二进制文件坏了（截断了），需要重新编译。

【问题讨论】：

你看过sourceware.org/gdb/onlinedocs/gdb/Threads.html吗？
根据这些信息我能想到的唯一答案是你不能通过随机猜测语法和含义来编程。相反，您必须积极了解程序的每个部分的作用以及它与其他部分的交互方式。看来这不是您的项目发展的方式。（我知道这对现在帮助不大，但您提供的诊断也不是。这对您的下一个项目来说是一个很好的教训。）
@user657267 我确实切换了线程，错误来自其中一个线程，但我不知道是哪个线程，并且回溯只有上述信息
@KerrekSB 你是对的，但有时有限的文档可能会很痛苦。我在我的项目中使用 libev，我认为这可能是我得到这个错误的部分。
根据我对线程问题的经验，您的更新完全没有对核心问题提供任何额外提示。您现在是否尝试过给定答案中提到的工具？他们没有结果？

标签： c++ multithreading segmentation-fault gdb

【解决方案1】：

对我来说，它看起来像是内存或堆栈覆盖或死指针或对象的访问。

为了捕捉这类错误，我喜欢使用efence 或valgrind 之类的工具。对于实际的编译器，您还可以使用thread sanitizer 或memory sanitizer。两者都适用于 clang 和 g++。

如果您无法发现问题，您还应该安装标准库的调试库版本。有时错误的值会在 g++lib 或其他一些库中崩溃，从而导致难以调试的情况。安装调试信息后，您可以更轻松地捕捉到这一点。

【讨论】：