OpenSSL の Python バインディングを利用する Linux アプリケーションがあり、それがランダムなクラッシュを引き起こしていると思われます。ときどき、次のメッセージでクラッシュすることがあります。
Python の致命的なエラー: GC オブジェクトは既に追跡されています
これは、ライブラリ側のプログラミング エラーか、メモリ破損の症状のいずれかであると思われます。コア ファイルを指定して、実行された Python ソース コードの最後の行を知る方法はありますか? または、GDBに添付されている場合は? おそらくすべてコンパイルされたバイトコードだと思いますが、誰かがこれに対処したことを願っています。現在、トレース モジュールがアクティブな状態で実行されており、再び発生することを期待していますが、しばらく時間がかかる可能性があります。
はい、あなたはこの種のことをすることができます：
(gdb) print PyRun_SimpleString("import traceback; traceback.print_stack()")
File "<string>", line 1, in <module>
File "/var/tmp/foo.py", line 2, in <module>
i**2
File "<string>", line 1, in <module>
$1 = 0
pystackpython gdbinitファイルで定義されたコマンドを使用することも可能ですが、私には機能しません。あなたがそれを調べたいならば、それはここで議論されます。
また、メモリの問題が疑われる場合valgrindは、再コンパイルする準備ができていれば、Pythonで使用できることに注意してください。手順はここで説明されています。
Mac または Sun ボックスを使用している場合は、dtraceと dtrace でコンパイルされたバージョンの python を使用して、その時点でアプリケーションが何をしていたかを把握できます。注: 10.5 では、Python は dtrace でプリコンパイルされています。これは非常に便利で便利です。
それが利用できない場合は、gc をインポートしてデバッグを有効にし、ログ ファイルに出力できます。
GDB を使用したデバッグに関する質問に具体的に答えるには、python wiki の「GDB を使用したデバッグ」を参照してください。
CDLLを使用してCライブラリをPythonでラップしていて、これが64ビットLinuxの場合、CDLLラッパーが正しく構成されていない可能性があります。CDLLは、デフォルトですべてのプラットフォームでint戻り型（64ビットシステムではlong longである必要があります）であり、正しい引数を渡すことを期待しています。この場合、CDLLラッパーを検証する必要があります...
上記のすべてに加えて、トレースモジュールを介してアドホックトレーサーをすばやく実装できます。