システムを激しくクラッシュさせる大きなシステムがあります。起動すると、コアダンプすらありません。システムがダウンするまで実行されるすべての行をログに記録するとします。私はその邪悪なコードを見つけます。
GDB のすべてのソース コード行をファイルに記録できますか?
アップデート：
わかりました、バグを見つけました。それは厄介でした。起動したアプリケーションはシステムを停止しませんでした。mdb を使用したコアダンプ インスペクションといくつかの gdb ステッピングについて学んだ後、ダンプの原因となっているシステム コールが実装されていないことがわかりました。システムを最新のカーネルに更新すると、問題が解決します。皆さんのお陰で。
私の教訓:
どのプロセスがコアダンプを引き起こしているかを確認してください。それはいつもあなたが始めたものではありません。
少しトリッキーな問題のように聞こえます。
私はよく、大量のコードをコメントアウトしたり、特定の部分を実行しないようにシステムを構成したり (実行できる場合) などして、可能な限り多くの容疑者を排除しようとします。これは、問題のあるコードを比較的迅速に特定するための驚くほど効果的な方法です。
ロギングに関する潜在的な問題は、システムがロックアップする前にログがディスクにヒットしない可能性があることです。コア ダンプを取得しないと、ログを取得できない可能性があります。
コア ダンプについて言えば、コア ダンプのサイズに制限がないことを確認してください (man ulimit.)。
objdump を使用してコード内のすべての関数のリストを取得し、それを少し処理して、それらの関数で一連の GDB トレース ステートメントを作成することができます。基本的には GDB スクリプトを自動的に作成します。それがやり過ぎであることが判明した場合は、トレースポイントを使用してコードをバイナリ検索することも、問題を拡大するのに役立ちます。
パニックにならないでください。あなたはバグよりも賢いです - あなたはそれを見つけるでしょう。
問題を明確にしてください：システムのどの部分がクラッシュしていますか？
アプリケーションですか？もしそうなら、どのアプリケーション？これはあなたが自分で書いたアプリケーションですか？これは他の場所から入手したアプリケーションですか？デバッガーを使用すると、クリーンな割り込みを取得できますか？クラッシュするコードのセクションを呼び出している関数を示すバックトレースを取得できますか？
新しいハードウェアドライバーですか？古いドライバーに基づいていますか？もしそうなら、何が変わったのですか？メーカーのデータシートに基づいていますか？そのデータシートは最新で最も正しいですか？
カーネルのどこかにありますか？どのカーネル？
OSとは何ですか？GNUデバッガーを使用しているので、Linuxだと思います。しかしもちろん、必ずしもそうとは限りません。
あなたはコアダンプがないと言います。マシンでコアダンプを有効にしましたか？最近のほとんどのシステムでは、デフォルトでコアダンプが有効になっていません。
GDB出力のログ記録に関しては、ある程度成功する可能性がありますが、システムがクラッシュする前に適切な出力がログに記録されるかどうかが問題の場所によって異なります。ディスクへの書き込みにはかなりの遅延があります。間に合わないかもしれません。
私はこれを行う gdb の方法に慣れていませんが、windbg を使用する方法は、デバッガーをカーネルに接続し、2 番目のデバッガーからシリアル ケーブル (またはファイヤーワイヤー) を介してデバッガーをリモートで制御することです。gdb にも同様の機能があると確信しています。ここでいくつかのヒントをすぐに見つけることができます: http://www.digipedia.pl/man/gdb.4.html