向用户显示异常调试信息

Question

我目前正在为我的 OSS 应用程序添加异常和异常处理。异常从一开始就是一个普遍的想法，但我想找到一个好的异常框架，老实说，在开始使用它们之前更好地理解 C++ 异常处理约定和习语。我在 C#/.Net、Python 和其他使用异常的语言方面拥有丰富的经验。我对这个想法并不陌生（但远非大师）。

在 C# 和 Python 中，当发生未处理的异常时，用户会得到一个很好的堆栈跟踪，并且通常会有很多 非常有用 无价的调试信息。如果您正在开发 OSS 应用程序，那么让用户将该信息粘贴到问题报告中是……好吧，让我们说我发现没有它就很难生活。对于这个 C++ 项目，我得到“应用程序崩溃”，或者来自更知情的用户，“我做了 X、Y 和 Z，然后它崩溃了”。但我也想要调试信息！

我已经（并且非常困难地）接受了这样一个事实：我永远不会看到跨平台和跨编译器的方式来获取 C++ 异常堆栈跟踪，但我知道我可以得到这个函数姓名和其他相关信息。

现在我想为我的未处理异常使用它。我正在使用boost::exception，他们有这个非常好的diagnostic_informationthingamajig，它可以打印出（未损坏的）函数名称、文件、行，最重要的是，程序员添加到该异常中的其他特定于异常的信息。

当然，我会尽可能地处理代码中的异常，但我并没有天真地认为我不会让一对夫妇溜走（当然是无意的）。

所以我想要做的是用catch 将我的主入口点包装在try 块中，这会创建一个特殊对话框，通知用户应用程序中发生了错误，并在何时显示更详细的信息用户单击“更多”或“调试信息”或其他任何内容。这将包含来自诊断信息的字符串。然后我可以指示用户将此信息粘贴到问题报告中。

但是一种烦人的直觉告诉我，将所有内容都包装在 try 块中是一个非常糟糕的主意。我要做的事是愚蠢的吗？如果是（即使不是），有什么更好的方法来实现我想要的？

Answer 1

在 main() 中放置一个 try/catch 块是可以的，它不会导致任何问题。无论如何，该程序因未处理的异常而死。但是，这对您获取最重要的堆栈跟踪完全没有帮助。当 catch 块捕获异常时，该信息是奇闻趣事。

捕获 C++ 异常也不会很有帮助。程序死于从 std::exception 派生的异常的可能性非常小。虽然它可能发生。在 C/C++ 应用程序中，由于硬件异常而死亡的可能性更大，AccessViolation 是 numero uno。捕获这些需要在 main() 方法中使用 __try 和 __except 关键字。同样，可用的上下文非常少，您基本上只有一个异常代码。 AV 还会告诉您哪个确切的内存位置导致了异常。

顺便说一句，这不仅仅是一个跨平台问题，您无法在任何平台上获得良好的堆栈跟踪。没有可靠的方法来遍历堆栈，有太多的优化（如帧指针遗漏）使这成为一个危险的旅程。这是 C/C++ 的方式：让它尽可能快，当它爆炸时不知道发生了什么。

您需要做的就是以 C/C++ 方式调试这类问题。您需要创建一个小型转储。它大致类似于旧的“核心转储”，即异常发生时进程映像的快照。那时，你实际上得到了一个完整的核心转储。已经取得了进展，现在它是“迷你”的，有点必要，因为完整的核心转储将需要接近 2 GB 的空间。它实际上可以很好地诊断程序状态。

在 Windows 上，通过调用 SetUnhandledExceptionFilter() 开始，您提供一个回调函数指针，该指针指向一个函数，该函数将在您的程序因未处理的异常而终止时运行。任何例外，C++ 以及 SEH。您的下一个资源是 dbghelp.dll，可在 Debugging Tools for Windows 下载中获得。它有一个名为 MiniDumpWriteDump() 的入口点，它会创建一个 minidump。

一旦你获得了由 MiniDumpWriteDump() 创建的文件，你就非常棒了。您可以在 Visual Studio 中加载 .dmp 文件，就像它是一个项目一样。按 F5 和 VS 磨了一会儿，试图为进程中加载​​的 DLL 加载 .pdb 文件。您需要设置符号服务器，这对于获得良好的堆栈跟踪非常很重要。如果一切正常，您将在引发异常的确切位置获得“调试中断”。带有堆栈跟踪。

您需要做的事情才能使这项工作顺利进行：

• 使用构建服务器创建二进制文件。它需要将调试符号（.pdb 文件）推送到符号服务器，以便在您调试 minidump 时随时可用。
• 配置调试器，以便它可以找到所有模块的调试符号。您可以从 Microsoft 获取 Windows 的调试符号，您的代码的符号需要来自上述符号服务器。
• 编写代码以捕获未处理的异常并创建小型转储。我提到了 SetUnhandledExceptionFilter() 但创建 minidump 的代码不应该在崩溃的程序中。它可以成功编写小型转储的可能性很小，程序的状态未确定。最好的办法是运行一个“守卫”进程来监视一个命名的 Mutex。您的异常过滤器可以设置互斥锁，守卫可以创建小型转储。
• 为小型转储创建一种从客户端计算机传输到您的计算机的方法。为此，我们使用了 Amazon 的 S3 服务，以合理的速率传输 TB。
• 将小型转储处理程序连接到您的调试数据库。我们使用 Jira，它有一个 Web 服务，允许我们根据具有相同“签名”的早期崩溃数据库验证崩溃存储桶。当它是唯一的或没有足够的命中时，我们会要求崩溃管理器代码将小型转储上传到 Amazon 并创建错误数据库条目。

嗯，这就是我为我工作的公司所做的。效果很好，它将崩溃桶的频率从数千减少到数十。给开源 ffdshow 组件创建者的个人信息：我非常讨厌你。但是您不再使我们的应用程序崩溃了！臭虫。

Answer 2

将所有代码封装在一个 try/catch 块中是可以的。例如，它不会减慢其中任何内容的执行速度。事实上，我所有的程序都有（代码类似）这个框架：

int execute(int pArgc, char *pArgv[])
{
    // do stuff
}

int main(int pArgc, char *pArgv[])
{
    // maybe setup some debug stuff,
    // like splitting cerr to log.txt

    try
    {
        return execute(pArgc, pArgv);
    }
    catch (const std::exception& e)
    {
        std::cerr << "Unhandled exception:\n" << e.what() << std::endl;
        // or other methods of displaying an error

        return EXIT_FAILURE;
    }
    catch (...)
    {
        std::cerr << "Unknown exception!" << std::endl;

        return EXIT_FAILURE;
    }
}

Answer 3

不，这并不愚蠢。这是一个非常好的主意，当然，在您遇到未处理的异常之前，它在运行时几乎没有任何成本。

请注意，已经有一个异常处理程序包装了您的线程，由操作系统提供（我认为另一个由 C 运行时提供）。您可能需要将某些异常传递给这些处理程序以获得正确的行为。在某些架构中，访问未对齐的数据由异常处理程序处理。所以你可能想要特例 EXCEPTION_DATATYPE_MISALIGNMENT 并让它传递给更高级别的异常处理程序。

我包括寄存器、应用程序版本和内部版本号、异常类型和十六进制的堆栈转储，其中注释模块名称和十六进制值的偏移量，这些值可能是代码的地址。请务必包含您的 exe 的版本号和内部版本号/日期。

您还可以使用VirtualQuery 将堆栈值轻松转换为“ModuleName+Offset”。而且，结合 .MAP 文件通常会告诉您确切的崩溃位置。

我发现我可以训练 beta 测试人员很容易地发送我的文本，但在早期，我得到的是错误对话框的图片而不是文本。我认为这是因为很多用户不知道您可以右键单击任何编辑控件以获取带有“全选”和“复制”的菜单。如果我要再做一次，我会添加一个按钮 将该文本复制到剪贴板，以便可以轻松地将其粘贴到电子邮件中。

如果您不想麻烦地使用“发送错误报告”按钮，那就更好了，但只是为用户提供一种将文本输入到他们自己的电子邮件中的方法可以让您大部分时间到达那里，并且不会引发关于“我与他们分享什么信息？”的任何危险信号？

Answer 4

事实上，boost::diagnostic_information 专门设计用于“全局”catch(...) 块中，以显示有关不应到达的异常的信息。但是，请注意 boost::diagnostic_information 返回的字符串不是用户友好的。