GDBを使用したPythonメモリデバッグ

Question

OpenSSLのPythonバインディングを使用するLinuxアプリケーションがあり、ランダムクラッシュを引き起こしていると思われます。時折、次のメッセージでクラッシュすることがあります：

  

Pythonの致命的なエラー：GCオブジェクトは既に追跡されています

これは、ライブラリの一部のプログラミングエラー、またはメモリ破損の兆候のいずれかと思われます。コアファイルを指定して、実行されたPythonソースコードの最後の行を知る方法はありますか？または、それがGDBに添付されている場合は？私はそれがおそらくすべてコンパイルされたバイトコードであることを知っていますが、私はそこに誰かがこれに対処したかもしれないことを望んでいます。現在、トレースモジュールがアクティブな状態で実行されており、再び発生することを期待していますが、しばらく時間がかかる可能性があります。

Answer 1

はい、あなたはこの種のことをすることができます：

(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

Python pystack コマンドを使用することも可能です。 = auto "rel =" noreferrer "> gdbinit ファイルですが、私にとっては機能していません。調べたい場合は、こちらで説明します。

また、メモリの問題が疑われる場合、 valgrind を使用できることに注意してください。再コンパイルする準備ができている場合は、Pythonを使用します。手順については、こちら

で説明しています。

Answer 2

macまたはsunボックスが動き回っている場合は、 dtrace とdtraceでコンパイルされたpythonは、その時点でアプリケーションが何をしていたかを把握します。注：10.5では、pythonはdtraceでプリコンパイルされており、非常に便利で便利です。

使用できない場合は、 gcをインポートしてデバッグを有効にし、ログファイルに出力できます。

GDBを使用したデバッグに関する質問に具体的に回答するには、＆quot; GDBでデバッグ＆quot; python wikiで。

Answer 3

PythonでCライブラリをラップするためにCDLLを使用しており、これが64ビットLinuxである場合、CDLLラッパーが正しく構成されていない可能性が高くなります。 CDLLはデフォルトですべてのプラットフォームでint戻り値の型（64ビットシステムではlong longである必要があります）に正しい引数を渡すことを期待しています。この場合、CDLLラッパーを確認する必要があるかもしれません...

Answer 4

上記のすべてに加えて、トレースモジュール。