私は大きなシステムを持っており、私のシステムクラッシュを激しくしています。私が起動すると、 コアダンプもありません。システムがダウンするまで、 が実行されるすべての行をログに記録します。私はその邪悪なコードを見つけるでしょう。私のカーネルをクラッシュさせる私のユーザランドコード内のポイントを見つける必要があります
GDBのすべてのソースコード行をファイルに記録できますか？
更新：
[OK]をクリックします。それは厄介でした。私が始めたアプリケーションは、 システムをダウンさせませんでした。 mdbでコアダンプ検査を学んだ後、gdbのステッピングを実行すると、ダンプを引き起こすシステムコールが実装されていないことがわかりました。システムを最新のカーネルにアップデートすると、私の問題が解決されます。あなた方全員に感謝します。
MY LESSON：
あなたがコアダンプを引き起こしどのようなプロセスを知っていることを確認してください。必ずしもあなたが始めたものではありません。
問題は微妙な問題です。
大量のコードをコメントアウトしたり、特定の部分を実行しないようにシステムを設定したり（これが可能な場合など）、可能な限り多くの容疑者を排除しようとします。これは、問題のバイナリ検索を可能にします。また、問題のコードを比較的迅速に拡大表示する驚くほど効果的な方法です。
ロギングの潜在的な問題は、システムがロックされる前にログがディスクにヒットしないことがあることです。コアダンプを取得しないと、ログが取得されない可能性があります。
コアダンプといえば、あなたのコアダンプサイズ（男性のulimit。）
上の制限はありませんあなたはobjdumpは使用してコード内のすべての関数のリストを取得するために試みることができることを確認し、プロセスそれを少しずつ作成して、これらの関数でGDBトレースステートメントを作成します。基本的には、自動的にGDBスクリプトを作成します。それが過度のものであることが判明した場合、トレースポイントを使用してコードをバイナリ検索すると、問題を拡大するのに役立ちます。
そして、パニックにはなりません。あなたはバグよりもスマートです - あなたはそれを見つけるでしょう。
私はこれをやっているgdbの方法に慣れていませんが、windbgではカーネルにデバッガを接続して、デバッガからシリアルケーブル（またはFirewire）を介してリモートでデバッガを制御する方法があります。私はかなりgdbに似た機能があると確信しています。ここでいくつかのヒントをすぐに見つけることができます：http://www.digipedia.pl/man/gdb.4.html
システムのどの部分がクラッシュしていますか？
アプリケーションですか？ その場合、どのアプリケーションですか？これは自分で書いたアプリケーションですか？これは他の場所から取得したアプリケーションですか？デバッガを使用するときれいな割り込みを得ることができますか？どの関数がクラッシュしたコードのセクションを呼び出しているかを示すバックトレースを取得できますか？
新しいハードウェアドライバですか？ これは古いドライバに基づいていますか？もしそうなら、何が変わったのですか？メーカーのデータシートに基づいていますか？そのデータシートは最新で最も正確ですか？
カーネルのどこかですか？どのカーネルですか？
OSとは何ですか？私はあなたがGNUデバッガを使っているのを見て、それがLinuxだと仮定します。しかし、もちろんそうではありません。
あなたはコアダンプがないと言っています。あなたのマシンでコアダンプを有効にしましたか？今日のほとんどのシステムでは、デフォルトで有効になっているコアダンプはありません。
ロギングGDBの出力に関しては、いくらか成功しているかもしれませんが、システムがクラッシュする前に正しい出力が記録されるかどうかは問題のどこに依存します。ディスクへの書き込みには多くの遅延があります。あなたは時間通りにそれをキャッチすることはできません。
GDBを使用してソースのすべての行を合理的に追跡することはできません（遅すぎます）。さらに、システムクラッシュはおそらくシステムコールの結果であり、libcはおそらくあなたの代わりにシステムコールを行っています。 OSのクラッシュを引き起こしたアプリケーションの行が見つかったとしても、あなたはまだ何も知らない。
まず、クラッシュするOSを明確にすることから始めてください。 Linuxの場合、次の方法を試すことができます。アプリケーションは、ちょうどクラッシュする前にやっていたシステムコールの再起動後、trace.outが含まれています
strace -fo trace.out /path/to/app
。あなたが運が良ければ、死の最後の鐘を見るでしょうが、私はそれを信じません。
また、user-mode Linux上、またはでコンパイルKGDBとカーネル上でクラッシュを再現してみてください。
カーネルに問題がある場合、これらはあなたを教えてくれます。アプリケーションで一致するシステムコールを見つけることは簡単なことです。
よろしくお願いいたします。それは時間がかかるでしょう。再起動は楽しいものではありません。トレースポイントを使用します。 – Flinkman
ちなみに、GDBのトレースポイントは、リモートデバッグとリモートデバッグが適切な場合にのみ機能します。 –