段错误仅在不使用调试器 [英] segfault only when NOT using debugger

问题描述

我有一个多线程的C程序，在程序中的特定点而持续产生分段错误。当我使用gdb运行，​​无故障显示。你能想到的任何理由不使用调试器的时候，为什么会只发生故障？这是pretty烦人不能够使用它来发现问题！

I have a multithreaded C program, which consistently generates a segmentation fault at a specific point in the program. When I run it with gdb, no fault is shown. Can you think of any reason why the fault might occur only when not using the debugger? It's pretty annoying not being able to use it to find the problem!

推荐答案

Heisenbug 。维基百科：

时间，也可以在heisenbugs一个因素。相比于正常的执行下一个调试控制执行程序可以改变程序的执行定时。当程序在调试器单步调试源代码行放缓对时间敏感的缺陷，如竞态条件可能不会再现。当行为包括用不调试器的控制下的一个实体的相互作用，这是特别真实的，例如在调试时网络分组处理两个机器之间，只有一个是调试器的控制下

Time can also be a factor in heisenbugs. Executing a program under control of a debugger can change the execution timing of the program as compared to normal execution. Time-sensitive bugs such as race conditions may not reproduce when the program is slowed down by single-stepping source lines in the debugger. This is particularly true when the behavior involves interaction with an entity not under the control of a debugger, such as when debugging network packet processing between two machines and only one is under debugger control.

调试器可以改变的时刻，和隐藏的竞争条件。

The debugger may be changing timing, and hiding a race condition.

在Linux中，GDB也将禁用的地址空间随机化，和你的崩溃可能是特定的地址空间布局。尝试（GDB）设置禁用随机化掉。

On Linux, GDB also disables address space randomization, and your crash may be specific to address space layout. Try (gdb) set disable-randomization off.

最后，的ulimit -c无限和事后调试（已被罗宾建议）可能工作。

Finally, ulimit -c unlimited and post-mortem debugging (already suggested by Robie) may work.

这篇关于段错误仅在不使用调试器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！