C语言 仅在不使用调试器时出现段错误
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/4628521/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
segfault only when NOT using debugger
提问by Benubird
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!
我有一个多线程 C 程序，它始终在程序中的特定点生成分段错误。当我用 gdb 运行它时，没有显示任何错误。你能想出什么原因导致只有在不使用调试器时才会出现故障吗？无法使用它来查找问题非常烦人！
回答by user541686
Classic Heisenbug. From Wikipedia:
经典海森虫。来自维基百科：
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.
时间也可能是 heisenbugs 的一个因素。与正常执行相比，在调试器的控制下执行程序可以改变程序的执行时序。当程序被调试器中的单步源代码行减慢时，诸如竞态条件之类的时间敏感错误可能不会重现。当行为涉及与不受调试器控制的实体进行交互时尤其如此，例如在调试两台机器之间的网络数据包处理并且只有一台在调试器控制下时。
The debugger may be changing timing, and hiding a race condition.
调试器可能正在改变时间，并隐藏竞争条件。
On Linux, GDB also disables address space randomization, and your crash may be specific to address space layout. Try (gdb) set disable-randomization off.
在 Linux 上，GDB 还禁用地址空间随机化，并且您的崩溃可能特定于地址空间布局。试试(gdb) set disable-randomization off。
Finally, ulimit -c unlimitedand post-mortem debugging (already suggested by Robie) may work.
最后，ulimit -c unlimited事后调试（已经由 Robie 建议）可能会起作用。
回答by SiegeX
Perhaps when using gdbmemory is mapped in a location which your over/under flow doesn't trample on memory that causes a crash. Or it could be a race condition that is no longer getting tripped. Although it sounds unintuitive, you should be happyyour program was nice enough to crash on you.
也许当使用gdb内存映射到一个位置时，您的溢出/下流不会践踏导致崩溃的内存。或者它可能是不再被绊倒的竞争条件。尽管这听起来不直观，但您应该很高兴您的程序足够好以至于您崩溃了。
Some suggestions
一些建议
回答by Mark Loeser
By debugging it you are changing the environment that it is running in. It sounds like you are dealing with some sort of race condition, and by debugging it things are scheduled slightly differently so you don't encounter the issue. That, or things are being stored in a slightly different way so it doesn't occur. Are you able to put some debugging output in the code to assist in figuring out the problem? That may have less of an impact and allow you to find your issue.
通过调试它，你正在改变它运行的环境。听起来你正在处理某种竞争条件，通过调试它，事情的安排略有不同，所以你不会遇到问题。那，或者事物的存储方式略有不同，因此它不会发生。你能在代码中加入一些调试输出来帮助找出问题吗？这可能影响较小，并允许您找到您的问题。
回答by rook
I have totally had this problem before! It was a race condition, and when I was stepping though the code with a debugger the thread i was in was slow enough to not trigger the race condition. Pretty awful.
我以前完全有这个问题！这是一个竞争条件，当我用调试器单步执行代码时，我所在的线程足够慢，不会触发竞争条件。好可怕。
