仅当不使用调试器时才出现段错误

发布于 2024-10-10 13:35:41 字数 105 浏览 0 评论 0原文

我有一个多线程 C 程序,它始终在程序中的特定点生成分段错误。当我用 gdb 运行它时,没有显示任何错误。您能想到只有在不使用调试器时才会出现该错误的任何原因吗?无法用它来查找问题,真是太烦人了!

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!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

居里长安 2024-10-17 13:35:41

经典的Heisenbug。来自维基百科:

时间也可能是海森错误的一个因素。与正常执行相比,在调试器的控制下执行程序可以改变程序的执行时序。当调试器中单步执行源代码行减慢程序速度时,诸如竞争条件之类的时间敏感错误可能不会重现。当行为涉及与不受调试器控制的实体交互时尤其如此,例如在调试两台机器之间的网络数据包处理且只有一台机器受调试器控制时。

调试器可能会改变时序并隐藏竞争条件。

在 Linux 上,GDB 还禁用地址空间随机化,并且您的崩溃可能特定于地址空间布局。尝试(gdb)设置禁用随机化关闭

最后,ulimit -c unlimited 和事后调试(Robie 已经建议)可能会起作用。

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.

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.

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

我要还你自由 2024-10-17 13:35:41

也许当使用 gdb 时,内存被映射到一个位置,您的溢出/下流不会践踏导致崩溃的内存。或者它可能是不再被绊倒的竞争条件。虽然这听起来不直观,但您应该高兴您的程序足够好,足以崩溃。

一些建议

  1. 尝试使用静态代码分析器,例如免费的
    cppcheck
  2. 尝试使用 malloc() 调试器喜欢
    libefence
  3. 尝试通过 valgrind

Perhaps when using gdb memory 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 happy your program was nice enough to crash on you.

Some suggestions

  1. Try a static code analyzer such as the free
    cppcheck
  2. Try a malloc() debugger like
    libefence
  3. Try running it through valgrind
神爱温柔 2024-10-17 13:35:41

通过调试它,您正在更改它运行的环境。听起来您正在处理某种竞争条件,并且通过调试它,事情的安排略有不同,因此您不会遇到问题。那,或者事物以稍微不同的方式存储,所以它不会发生。您能否在代码中添加一些调试输出来帮助找出问题?这可能影响较小,并且可以让您找到问题。

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.

浮萍、无处依 2024-10-17 13:35:41

我以前完全遇到过这个问题!这是一个竞争条件,当我使用调试器单步执行代码时,我所在的线程足够慢,无法触发竞争条件。非常糟糕。

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.

花海 2024-10-17 13:35:41

如果您使用的是 gcc,请尝试使用 -Wall 选项来获取所有警告。如果您使用像 Eclipse 这样的 IDE,它会自动执行此操作。

If you're using gcc, try using the -Wall option to get all warnings. If you use an IDE like Eclipse, it would do that automatically.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文