当断言失败或存在分段错误时,发生以下情况之一将非常方便:
- 程序询问是否运行调试器。
- 程序等待崩溃,直到附加调试器。
- 程序留下了一些东西(核心转储?),我们可以从这一点恢复执行并进行调查。
由于平台、语言和调试器的多样性,这个问题非常笼统。我问的是 C++,我猜 Windows (VS)、Linux (gdb)、Mac (gdb?) 解决方案对社区最有用。我对 Linux + gdb 感兴趣。
当断言失败或存在分段错误时,发生以下情况之一将非常方便:
由于平台、语言和调试器的多样性,这个问题非常笼统。我问的是 C++,我猜 Windows (VS)、Linux (gdb)、Mac (gdb?) 解决方案对社区最有用。我对 Linux + gdb 感兴趣。
在 Linux(可能还有 OSX 和其他 unixen)上,您可以允许程序使用该ulimit
实用程序保留核心转储。
这是一个快速操作方法。
在 Windows 上,有DebugBreak()
(and ),这是失败IsDebuggerPresent()
时可能发生的情况的选项之一。assert
在 MacOS 上有类似的 API 调用(Debugger()
或SysBreak()
)。
我对 Linux 了解不多,但是 AFAIK 在 Linux 上的失败断言会导致核心转储,可以在调试器中查看。
不幸的是,我的回应仅适用于 Windows,但 Linux 也可以通过某种方式向调试器发出信号是有道理的。
任何安装了 Visual Studio 的机器都应该启用即时调试。这实质上意味着当进程遇到致命异常时,调试器不必运行。
通过注册表项启用即时调试。查看上面的链接以获取更多详细信息。
如果您希望捕获进程快照以供稍后查看,那么这通常通过 Adplus.vbs(有人参与)或 DebugDiag(无人参与)来完成。Adplus 可通过Debugging Toolkit for Windows 获得,但DebugDiag需要单独下载。
除了 gnud 建议的 ulimit 之外,使用崩溃报告器可能是个好主意:http ://code.google.com/p/google-breakpad/w/list
我已经在https://github.com/l29ah/waitgdbLD_PRELOAD
中实现了这样的功能作为一个有能力的库
基本上,它处理值得调试的信号并停止发送它的进程,SIGSTOP
以便您以后可以附加调试器。