クラッシュするバグは最も厄介なバグで、データの損失、ダウンタイム、イライラするユーザーにつながる可能性があります。アプリケーションのクラッシュが少なくなればよいでしょう。
マシンコンテキストは複雑であるため、クラッシュは通常のユーザーにとって妥当な時間内に再現できないことがよくあります。これは、バグがまれであることを意味しているわけではありません。単に、それをトリガーするものが、各ユーザー（DSTの変更など）でまれにしか発生しないことを意味している可能性があります。このようなバグは、多くのユーザーが報告しない限り、修正される見込みはありません。さらに多くのクラッシュが報告された場合、それは良いことです。
クラッシュをデバッグするには、開発者は可能な限り明確なコンテキストを必要とします。生成されたクラッシュレポートは、通常、詳細で正確であるため、優れています。ユーザーは、すべてのコンテキストを手動で熱心に観察して報告することは期待できないため、まばらで間違った情報を送信することがよくあります。
多くのアプリケーションの対象読者は、開発者やシステム管理者ではなく、自宅や職場の一般大衆です。このようなユーザーは、クラッシュ情報を手動で収集する方法や-dbgパッケージをインストールする方法を知ることはできませんが、そのようなユーザーから生成されたレポートは引き続き使用できます。一部のアプリケーションには独自のクラッシュレポートツールがありますが、私の経験ではこれらが機能することはめったになく、エラーを報告できなかったと報告された場合、手動で行う方法についての情報がないようです（私はこれを観察しましたFirefoxとFlashの両方の最新バージョン）。システム全体でのクラッシュレポートの生成は適切です。
大量の-dbgパッケージをインストールしたり、すべてのアプリケーションのドキュメントを読んだり、通常のマシンをクロールする速度を落としたりせずに、グローバルに有効化できる何らかの種類のクラッシュレポート生成*はありますか？
*ログ、コアダンプ、スタックトレースなど
**必ずしも必要でinitはありませんが、少なくとも、典型的なデスクトップLinuxインストールで実行されているアプリケーションの重要なサブセットでは必要です。私の経験では、GUIアプリケーションはシェルアプリケーションよりも100倍以上頻繁にクラッシュするため、当然GUIアプリケーションが焦点になります。