奇妙な状態の Python アプリケーションがあります。私はプロセスのライブデバッグをしたくありません。ファイルにダンプして、後でその状態を調べることはできますか? 後で gdb で C プログラムのコアファイルを復元したことは知っていますが、gdb から便利な方法で Python アプリケーションを調べる方法がわかりません。
(これは、本番システムでの memleaks のデバッグに関する私の質問のバリエーションです。)
奇妙な状態の Python アプリケーションがあります。私はプロセスのライブデバッグをしたくありません。ファイルにダンプして、後でその状態を調べることはできますか? 後で gdb で C プログラムのコアファイルを復元したことは知っていますが、gdb から便利な方法で Python アプリケーションを調べる方法がわかりません。
(これは、本番システムでの memleaks のデバッグに関する私の質問のバリエーションです。)
(os.abort() を使用して、リソース制限で許可されている場合はコアダンプを発生させる) 中止以外の組み込みの方法はありません。そのための既製のツールはありません。
Python プロセスのコアファイルの処理に関しては、 Python ソースには便利なマクロを含むgdbinit ファイルがあります。何らかの方法でプロセス自体 (pdb または対話型インタープリターを使用) に入るよりもはるかに苦痛ですが、生活が少し楽になります。
プロセスからすべてのデータをダンプするようなものを書くことも可能です。
dir()
とする可能性もあります)。getattr()
しかし、実行中のプロセスをマンホールやパイロンなどで残すことは、可能であれば確かに便利なようです。
(また、この質問が最初に尋ねられて以来、もっと便利なものが書かれたのだろうか)
上記の誰かが、これを実行する組み込みの方法はないと言いましたが、それは完全に真実ではありません。例として、pylons デバッグ ツールを見てみましょう。例外が発生すると、例外ハンドラーはスタック トレースを保存し、HTTP 経由でデバッグ セッションを取得するために使用できる URL をコンソールに出力します。
これらのセッションはメモリ内に保持されている可能性がありますが、それらは単なる Python オブジェクトであるため、スタック ダンプをピクルして後で検査のために復元することを妨げるものは何もありません。それはアプリへのいくつかの変更を意味しますが、それは可能であるはずです...
いくつかの調査の結果、関連するコードは実際には Paste のEvalException モジュールから来ていることがわかりました。そこを見て、何が必要かを理解できるはずです。
この回答は、プログラムのコアダンプを作成してから、十分に類似した別のボックスで実行を継続することを提案しています。