崩溃的错误可能是最令人讨厌的错误，从而导致数据丢失，停机和用户受挫。如果应用程序崩溃更少，那将是很好。
由于机器上下文的复杂性，对于普通用户而言，通常无法在合理的时间内重现崩溃。这并不意味着该错误是罕见的-可能只是意味着触发该错误的事件很少针对每个用户发生（例如DST更改）。除非有许多用户报告，否则此类错误不太可能得到修复。如果报告了更多的崩溃，那就很好了。
要调试崩溃，开发人员需要尽可能多的明确上下文。生成的崩溃报告很好，因为它们通常是详细而准确的。不能指望用户热心地手动观察和报告所有上下文，因此他们经常提交稀疏和错误的信息。
许多应用程序的目标受众不是开发人员或系统管理员，而是家庭或工作中的普通公众。不能期望这类用户知道如何手动收集崩溃信息或安装-dbg软件包，但是仍然可以使用由此类用户生成的报告。某些应用程序具有自己的崩溃报告工具，但以我的经验，这些工具很少起作用，当它们报告未能报告错误时，似乎没有有关如何手动执行此操作的信息（我观察到了Firefox和Flash的最新版本）。在整个系统范围内生成崩溃报告会很好。
是否可以在不安装大量-dbg程序包，不阅读每个应用程序文档或使正常计算机运行缓慢的情况下在全球范围启用**的崩溃报告生成* ？
*日志，核心转储，堆栈跟踪等
**不一定适用init，但至少适用于在典型的桌面Linux安装上运行的大部分应用程序。以我的经验，GUI应用程序崩溃的频率比Shell应用程序高100倍以上，因此GUI应用程序自然会成为焦点。
您将如何处理所有这些核心文件（是的，您可以全局启用核心转储，但应用程序可以单独禁用它们）？您如何教育用户如何处理用户，如何清理用户？
—
2012年
将它们发送给开发人员。至少其中大多数人应该熟悉电子邮件附件。
—
l0b0 2012年
那么安全问题呢？核心转储中可能充满了个人信息。很抱歉，但是您提出的建议中没有任何普遍适用的内容。
—
2012年
另一方面，崩溃报告和堆栈跟踪不应包含任何个人信息。即使它们仅在默认情况下生成且易于查找，也足以调试许多应用程序。
—
l0b0
如果没有调试信息（或者至少带有它们的确切二进制版本），堆栈跟踪并不是那么有用。“崩溃报告”是应用程序级的概念，不是您可以“全局启用”的内容（尽管某些框架提供了这些框架，而大型框架（例如KDE）已经具有自动的“发送至开发团队”功能）。
—
垫子