C++ 是什么导致调试会话中出现 Sigtrap

What causes a Sigtrap in a Debug Session

提问by zitroneneis

In my c++ program I'm using a library which will "send?" a Sigtrap on a certain operations when I'm debugging it (using gdb as a debugger). I can then choose whether I wish to Continue or Stop the program. If I choose to continue the program works as expected, but setting custom breakpoints after a Sigtrap has been caught causes the debugger/program to crash.

在我的 C++ 程序中，我使用了一个可以“发送？”的库。当我调试某个操作时（使用 gdb 作为调试器）的一个 Sigtrap。然后我可以选择是要继续还是停止该程序。如果我选择继续程序按预期工作，但在捕获 Sigtrap 后设置自定义断点会导致调试器/程序崩溃。

So here are my questions:

所以这里是我的问题：

1. What causes such a Sigtrap? Is it a leftover line of code that can be removed, or is it caused by the debugger when he "finds something he doesn't like" ?
2. Is a sigtrap, generally speaking, a bad thing, and if so, why does the program run flawlessly when I compile a Release and not a Debug Version?
3. What does a Sigtrap indicate?

1. 是什么导致了这样的 Sigtrap？它是可以删除的剩余代码行，还是由调试器“发现他不喜欢的东西”引起的？
2. 一般来说，一个 sigtrap 是一件坏事，如果是这样，为什么当我编译一个发行版而不是一个调试版本时程序可以完美运行？
3. Sigtrap 表示什么？

This is a more general approach to a question I posted yesterdayBoost Filesystem: recursive_directory_iterator constructor causes SIGTRAPS and debug problems.
I think my question was far to specific, and I don't want you to solve my problem but help me (and hopefully others) to understand the background.

这是我昨天发布的Boost Filesystem: recursive_directory_iterator 构造函数导致 SIGTRAPS 和调试问题的更一般方法。
我认为我的问题很具体，我不希望您解决我的问题，而是帮助我（希望其他人）了解背景。

Thanks a lot.

非常感谢。

回答by sarnold

With processors that support instruction breakpoints or data watchpoints, the debugger will ask the CPU to watch for instruction accesses to a specific address, or data reads/writes to a specific address, and then run full-speed.

对于支持指令断点或数据观察点的处理器，调试器会要求 CPU 观察对特定地址的指令访问，或对特定地址的数据读/写，然后全速运行。

When the processor detects the event, it will trap into the kernel, and the kernel will send SIGTRAP to the process being debugged. Normally, SIGTRAP would kill the process, but because it is being debugged, the debugger will be notified of the signal and handle it, mostly by letting you inspect the state of the process before continuing execution.

当处理器检测到事件时，它会陷入内核，内核会向被调试的进程发送 SIGTRAP。通常，SIGTRAP 会终止进程，但因为它正在被调试，调试器将收到信号通知并处理它，主要是让您在继续执行之前检查进程的状态。

With processors that don't support breakpoints or watchpoints, the entire debugging environment is probably done through code interpretation and memory emulation, which is immensely slower. (I imagine clever tricks could be done by setting pagetable flags to forbid reading or writing, whichever needs to be trapped, and letting the kernel fix up the pagetables, signaling the debugger, and then restricting the page flags again. This could probably support near-arbitrary number of watchpoints and breakpoints, and run only marginally slower for cases when the watchpoint or breakpoint aren't frequently accessed.)

对于不支持断点或观察点的处理器，整个调试环境可能是通过代码解释和内存模拟来完成的，这非常慢。（我想聪明的技巧可以通过设置分页表标志来禁止读或写，无论哪个需要被困，让内核修复分页表，向调试器发出信号，然后再次限制页面标志。这可能支持近-任意数量的观察点和断点，并且对于不经常访问观察点或断点的情况，运行速度只会稍微慢一些。）

The question I placed into the comment field looks apropos here, only because Windows isn't actually sending a SIGTRAP, but rather signaling a breakpoint in its own native way. I assume when you're debugging programs, that debug versions of system libraries are used, and ensure that memory accesses appear to make sense. You might have a bug in your program that is papered-over at runtime, but may in fact be causing further problems elsewhere.

我放在评论字段中的问题在这里看起来很合适，只是因为 Windows 实际上并没有发送 SIGTRAP，而是以自己的本机方式发出断点信号。我假设当您调试程序时，使用系统库的调试版本，并确保内存访问似乎有意义。您的程序中可能有一个在运行时被掩盖的错误，但实际上可能会在其他地方引起进一步的问题。

I haven't done development on Windows, but perhaps you could get further details by looking through your Windows Event Log?

我还没有在 Windows 上进行过开发，但也许您可以通过查看 Windows 事件日志来获得更多详细信息？

回答by Hack06

While working in Eclipse with minGW/gcc compiler, I realized it's reacting very bad with vectors in my code, resulting to an unclear SIGTRAP signal and sometimes even showing abnormal debugger behavior (i.e. jumping somewhere up in the code and continuing execution of the code in reverse order!).

在 Eclipse 中使用 minGW/gcc 编译器工作时，我意识到它对我代码中的向量的反应非常糟糕，导致 SIGTRAP 信号不明确，有时甚至显示异常调试器行为（即在代码中跳到某个地方并继续执行代码相反的顺序！）。

I have copied the files from my project into the VisualStudio and resolved the issues, then copied the changes back to eclipse and voila, worked like a charm. The reasons were like vector initialization differences with reserve() and resize() functions, or trying to access elements out of the bounds of the vector array.

我已将项目中的文件复制到 VisualStudio 中并解决了问题，然后将更改复制回 eclipse 和 voila，效果非常好。原因就像是与reserve() 和resize() 函数的向量初始化差异，或者试图访问向量数组边界之外的元素。

Hope this will help someone else.

希望这会帮助别人。