只有在不使用debugging器的情况下才能执
我有一个multithreading的C程序，它在程序中的特定点处始终产生分段错误。 当我用gdb运行它时，没有显示错误。 你能想到为什么只有在不使用debugging器时才会发生故障的原因吗？ 这是非常烦人的不能用它来find问题！
经典的海森堡 。 维基百科：
时间也可能是海森堡的一个因素。 在正常执行的情况下，在debugging器的控制下执行程序可以改变程序的执行时间。 当debugging器中的单步debugging源代码行导致程序速度减慢时，时间敏感的错误（如竞争条件）可能无法重现。 当行为涉及与不在debugging器控制下的实体进行交互时（例如在两台机器之间debuggingnetworking数据包处理并且只有一个在debugging器控制下时），情况尤其如此。
debugging器可能正在改变时间，并隐藏竞争条件。
在Linux上，GDB也禁用地址空间随机化，而且崩溃可能是特定于地址空间布局的。 尝试(gdb) set disable-randomization off 。
最后， ulimit -c unlimited和验尸debugging（Robie已经提出）可能会起作用。
也许当使用gdb内存映射的位置，你的上/下stream不会在导致崩溃的内存上践踏。 或者它可能是一个不再被绊倒的竞赛条件。 虽然听起来很不直观，但你应该感到高兴，你的程序已经足够让你崩溃了。
一些build议
- 尝试一个静态代码分析器，如免费的cppcheck
- 尝试像libefence一样的malloc（）debugging器
- 尝试通过valgrind运行
通过debugging它，你正在改变它运行的环境。这听起来像你正在处理某种竞争条件，并通过debugging它的事情安排稍有不同，所以你不会遇到问题。 那或者东西被以一种稍微不同的方式存储，所以它不会发生。 你能够在代码中join一些debugging输出来帮助解决问题吗？ 这可能没有什么影响，并允许你find你的问题。
我以前完全有这个问题！ 这是一个竞争条件，当我用debugging器join代码时，我所在的线程足够慢，不会触发竞争条件。 太可怕了
