等待调试器崩溃？答案

【问题标题】：Waiting with a crash for a debugger?等待调试器崩溃？
【发布时间】：2009-09-23 11:07:11
【问题描述】：

当一个断言失败或存在分段错误时，发生以下情况之一将非常方便：

由于平台、语言和调试器的多样性，这个问题非常笼统。我问的是 C++，我猜 Windows (VS)、Linux (gdb)、Mac (gdb?) 解决方案对社区最有用。我对 Linux + gdb 感兴趣。

【问题讨论】：

【解决方案1】：

在 Linux（可能还有 OSX 和其他 unixen）上，您可以使用 ulimit 实用程序允许程序离开核心转储。

这是一个快速的howto。

【讨论】：

【解决方案2】：

在 Windows 上，有DebugBreak()（和IsDebuggerPresent()），这是assert 失败时可能发生的选项之一。

在 MacOS 上也有类似的 API 调用（Debugger() 或 SysBreak()）。

我对 Linux 了解不多，但 AFAIK 在 Linux 上的断言失败会导致核心转储，可以在调试器中查看。

【讨论】：

【解决方案3】：

在 Linux 上，基本上当可怕的事情发生时，你的程序会收到一个signal，如果你不“屏蔽”这个信号，程序会有一个默认行为，但你通常可以“屏蔽”它来做其他事情，比如打开gdb。您可以从 here，特别是 here 找到如何屏蔽以及更多信息。

关于断言，您可以轻松创建自己的断言版本，做任何您想做的事情。

【讨论】：

【解决方案4】：

不幸的是，我的回应仅适用于 Windows，但 Linux 也可以通过某种方式向调试器发出信号。

任何安装了 Visual Studio 的机器都应该启用Just in Time 调试。这实质上意味着当进程遇到致命异常时，调试器不必运行。

通过注册表项启用即时调试。查看上面的链接了解更多详情。

如果您希望捕获进程快照以供稍后查看，则通常通过 Adplus.vbs（有人参与）或 DebugDiag（无人参与）来完成。 Adplus 可通过Debugging Toolkit for Windows 获得，但DebugDiag 需要单独下载。

【讨论】：

【解决方案5】：

除了 gnud 建议的 ulimit 之外，使用崩溃报告器可能是个好主意：http://code.google.com/p/google-breakpad/w/list

【讨论】：

【解决方案6】：

我在https://github.com/l29ah/waitgdb 中实现了LD_PRELOADable 库等功能

基本上，它处理值得调试的信号并停止发送它SIGSTOP 的进程，以便您以后可以附加调试器。

【讨论】：