在生产环境中保持可调试性的同时优化构建 C++ 程序的最佳实践

Question

我正在编写一个 C++ 服务器程序，将部署到 *nix 系统（Linux/macOS）。程序有时在生产环境中会遇到段错误，我想收集一些信息，例如核心转储文件。但我不知道这样做的最佳实践是什么：

我了解到有些事情我可以尝试：

我是部署生产C++服务器程序的新手，我想知道以下问题的答案：

总的来说，我想知道如何建议为生产构建 C++ 程序，以便在我仍然能够对其进行故障排除的同时对其进行最佳优化。非常感谢。

Answer 1

这将是一个相当笼统的答案。

如果您仍然遇到可靠性问题，请选择
```
RelWithDebInfo
```
。或者，您可以覆盖
```
-O2
```
优化，让编译器全程优化。
当存在调试信息时，您需要
```
strip
```
。这不会改变任何实际执行的内容，但会删除使调试变得更加容易的内容。您仍然可以调试剥离的可执行文件，但更难理解发生了什么。
不，由于优化级别不同。如果两者之间唯一的区别是一个被剥夺了而另一个没有被剥夺，那么是的。但不同的优化级别，最终的组装结果实际上会有所不同。
通常不建议在生产环境中启用核心转储，主要是出于安全原因。例如，核心转储可能包含纯文本密码、会话令牌等。这些都是其他人不应该看到的东西。如果您可以完全控制运行该程序的机器，那么这个问题就会稍微小一些。另一个问题是磁盘空间使用情况。核心转储可能会很大，具体取决于您的程序正在执行的操作。如果你有固定的核心文件名，那么至少不会有超过一个文件，但如果你有一个包含时间戳和/或 PID 的名称，那么你可以有多个文件，每个文件占用很多 - GB 的大小 -的空间。这可能会再次导致问题。

一般规则是（或应该是）您认为发布环境是敌对的。有时这是真的，有时则不然——这里不能适用一般性，因为只有你知道你的具体情况。

我总是部署我的东西完全优化。如果程序特别有问题，我只会包含调试信息，因为这样可以轻松运行它或使用

gdb

附加到它。

全面优化的缺点是有时事情看起来与您编写的代码有点不同。事情的顺序可能会改变，有些事情可能根本不会发生，并且您可能会发现某些函数实际上并不作为正确的独立函数存在，因为编译器认为内联它们会更好。这些是我观察到的变化，但可能还有其他变化。

Answer 2

最近我了解到有像Google Breakpad这样的工具可以生成小型转储格式的崩溃报告，可以在生产环境中收集和分析。我还没有尝试过，但它对于这个确切的目的可能很有用。