5

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

  • 程序询问是否运行调试器。
  • 程序等待崩溃，直到附加调试器。
  • 程序留下了一些东西（核心转储？），我们可以从这一点恢复执行并进行调查。

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

4

6 回答 6

3

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

这是一个快速操作方法。

于 2009-09-23T11:24:46.307 回答
2

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

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

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

于 2009-09-23T11:21:20.313 回答
1

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

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

通过注册表项启用即时调试。查看上面的链接以获取更多详细信息。

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

于 2009-09-23T12:08:08.720 回答
1

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

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

于 2009-09-23T11:23:37.580 回答
0

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

于 2010-07-23T11:07:02.273 回答
0

我已经在https://github.com/l29ah/waitgdbLD_PRELOAD中实现了这样的功能作为一个有能力的库

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

于 2019-08-15T16:23:47.027 回答