私はpdbで直接デバッグするのがとても新しく、Djangoアプリケーションのデバッグにいくつかの問題があります。ここに私がやっていることがあります：PDBはブレークポイントで停止しません
python -m pdb manage.py runserver
(pdb) b core/views.py:22
Breakpoint 2 at /Users/raphaelcruzeiro/Documents/Projects/pdb_test/core/views.py:22
(Pdb) c
しかし、実行はブレークポイントを直接通ります。私はいくつかのコマンドを欠いていますか？このマニュアルではこれ以上ブレークポイントを設定することは詳しく述べていません。
私は同じ問題を抱えています。
python -m pdb ./manage.py runserver --nothreading --noreload 127.0.0.1:8080のように試してください。それは私の問題を解決しました。
PDBのブレークポイントはスレッド固有で、PDBを混乱させる可能性のあるフォークを避けるためには、--nothreadingと--noreloadオプションが必要です。これは、なぜ関心のあるスレッドの中で直接呼び出されるので、set_traceが機能する理由です。
他のモードでこれを行う方法に関するアイデア（特に、test ）？ --nothreadingは実行サーバーのみであるように見えます。 –
通常、ソース自体にはset_trace()が好きです。つまり、追加/削除するとdevサーバーがリロードされ、もう一度停止して再起動する必要はありません。たとえば、次のように。
def get_item(request):
import pdb; pdb.set_trace()
ビューにアクセスすると、PDBがでキックします
私は過去にこの問題を見てきたときに誰かがいないの行にブレークポイントを設定しているため、それが通常です実行されるPython文に実際に接続されます。たとえば、空白行、コメント行、複数行のステートメントの間違った部分などです。
私が気付いたことの1つは、繰り返し打ったときにPDBプロンプトが以前の動作を繰り返すことです。さらに、プログラムの実行中にEnterキーを押すと、PDBは入力をバッファし、プロンプトが表示されたらそれを適用します。私の場合は、PDB c（ontinue）を使用してプログラムを実行していました。私のプログラムは、初期化中に多くのデバッグ情報をstdoutに書き込んでいたので、ブレークポイントがトリガーされたときに書き込まれる出力からすでに書き込まれた出力を分離するために、何回か入力してください。その後、私はいくつかの外部アクションを介してブレークポイントをトリガしたとき、PDBはブレークポイントで停止しますが、c（ontinue）アクションを繰り返す 'buffered enter'を適用します。私が打つのを止めたら、それはすべて正常に動作するようになった。
これは少し奇妙に思えるかもしれませんが、私はこの問題を多く調査していませんが、それは私の問題を解決しました。たぶんそれは他の人を助けるかもしれない。
例外はありません。デバッガが接続されていないかのようにコードが実行されます。 – Raphael
エラーメッセージだけでなく、この問題を示す小さなコードを投稿してください。 –