c++ - 是什么导致调试 session 中出现 Sigtrap

Question

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

所以这是我的问题:

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

这是我昨天发布的问题的更通用方法 Boost Filesystem: recursive_directory_iterator constructor causes SIGTRAPS and debug problems .
我认为我的问题很具体，我不希望您解决我的问题，而是帮助我(希望其他人)了解背景。

非常感谢。

Answer 1

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

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

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

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

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