pydevブレークポイントが機能しない
python 2.7.2、sqlalchemy 0.7、unittest、Eclipse 3.7.2、pydev2.4を使用してプロジェクトに取り組んでいます。pythonファイルにブレークポイントを設定しています（単体テストファイル）が、完全に無視されます（以前は、ある時点で機能していました）。これで、関連するすべてのソフトウェアをアップグレードし（上記を参照）、新しいプロジェクトを開始し、設定を試して、画面に催眠術をかけましたが、何もありません動作します。
私がいくつかの投稿から得た唯一のアイデアは、いくつかの.pyファイル名を小文字に変更することと関係があるということです。
誰かアイデアはありますか？
追加： Eclipseのaptanaバージョンをインストールし、それに.pyファイルをコピーしました=>同じ結果;ブレークポイントは引き続き無視されます。
まだ進捗がありません：異常と見なされる可能性のあるコードを変更し、より簡単なソリューションに置き換えました。
もう少し情報：おそらくモジュールユニットテストと関係があります：
- テストスイートを定義するファイル内のブレークポイントは機能しますが、
- 標準のユニットテストファイル自体のブレークポイントは機能します
- unittest.TestCaseから派生したクラスのテストメソッドのブレークポイントが機能しない
- テストケースでテストされているコードのブレークポイントが機能しない
- テストメソッドまたはテスト対象のコードで作業ブレークポイントを定義する前のある時点で
- その後変更したものは次のとおりです。テストスイートの使用を開始し、いくつかのファイル名を小文字に変更しました。
- この問題は、コードが例外やテストの失敗なしに機能する場合にも発生します。
私がすでに試したことは：
.pycファイルを削除します- 新しいプロジェクトを定義し、
.pyファイルのみをプロジェクトにコピーします - その間に数回再起動しました
- eclipse3.7.2にアップグレード
- eclipse3.7.2に最新のpydevをインストールしました
- aptanaに切り替えます（そして元に戻します）
- モジュールにクラスを「手動で」追加するコードを削除しました
- いくつかの構成をいじる
私がまだできることは：
- 私のコードで新しいプロジェクトを開始し、ブレークポイントが機能するまでコードの削除/変更を開始し、ブラックボックスのようなものがこれが私のコードの一部と関係があるかどうかを判断します
- 誰かがこれらの問題を引き起こす可能性があるもの、またはそれらがどのように解決される可能性があるかについて何か考えがありますか？
- 私が解決策を探すことができる他の場所はありますか？
- Pydev開発者はstackoverflowに関する質問を調べますか？
- 私が試すかもしれない古いバージョンのpydevはありますか？
私は長い間pydev/Eclipseを使用していて、それは私にとってはうまく機能しますが、デバッグせずにIDEを切り替えることを余儀なくされました。
以下のFabioの質問への回答：
- pythonバージョンは2.7.2、
- Sys.gettraceはNoneを返します（ただし、コード内で何がそれに影響を与える可能性があるのかわかりません）
- これは、提案されたパラメーターを変更した後のデバッガーの出力です。
pydevデバッガー：
starting
('Executing file ', 'D:\\.Eclipse\\org.Eclipse.platform_3.7.0_248562372\\plugins\\org.python.pydev.debug_2.4.0.2012020116\\pysrc\\runfiles.py')
('arguments:', "['D:\\\\.Eclipse\\\\org.Eclipse.platform_3.7.0_248562372\\\\plugins\\\\org.python.pydev.debug_2.4.0.2012020116\\\\pysrc\\\\runfiles.py', 'D:\\\\Documents\\\\Code\\\\Eclipse\\\\workspace\\\\sqladata\\\\src\\\\unit_test.py', '--port', '49856', '--verbosity', '0']")
('Connecting to ', '127.0.0.1', ':', '49857')
('Connected.',)
('received command ', '501\t1\t1.1')
sending cmd: CMD_VERSION 501 1 1.1
sending cmd: CMD_THREAD_CREATE 103 2 <xml><thread name="pydevd.reader" id="-1"/></xml>
sending cmd: CMD_THREAD_CREATE 103 4 <xml><thread name="pydevd.writer" id="-1"/></xml>
('received command ', '111\t3\tD:\\Documents\\Code\\Eclipse\\workspace\\sqladata\\src\\testData.py\t85\t**FUNC**testAdjacency\tNone')
Added breakpoint:d:\documents\code\Eclipse\workspace\sqladata\src\testdata.py - line:85 - func_name:testAdjacency
('received command ', '122\t5\t;;')
Exceptions to hook : []
('received command ', '124\t7\t')
('received command ', '101\t9\t')
Finding files... done.
Importing test modules ... testAtomic (testTypes.TypeTest) ... ok
testCyclic (testTypes.TypeTest) ...
残りはユニットテストの出力です。
ファビオの答えパート2から続く：
プログラムの開始時にコードを追加しましたが、デバッガーはsqlalchemy\orm\attributes.pyのメソッドに従う最後の行で動作を停止します（これは記述子ですが、デバッグに干渉する方法または方法は私の範囲を超えています現在の知識）：
class InstrumentedAttribute（QueryableAttribute）： "" "記述子メソッドを追加するクラスバインドされたインストルメント化属性。" ""
def __set__(self, instance, value):
self.impl.set(instance_state(instance),
instance_dict(instance), value, None)
def __delete__(self, instance):
self.impl.delete(instance_state(instance), instance_dict(instance))
def __get__(self, instance, owner):
if instance is None:
return self
dict_ = instance_dict(instance)
if self._supports_population and self.key in dict_:
return dict_[self.key]
else:
return self.impl.get(instance_state(instance),dict_) #<= last line of debugging
そこから、デバッガーはsqlalchemyのdeclarative_base（）クラスから派生した自分のクラスの1つの__getattr__メソッドにステップインします。
おそらく解決されました（理解されていませんが）：
問題は、上記の__getattr__が無限再帰に似たものを作成したことであるように見えましたが、program/unittest/sqlalchemyはエラーを報告せずに回復しました。 __getattr__メソッドが呼び出された理由を理解するのに十分なsqlalchemyコードを理解していません。
再帰が発生した属性名（おそらく私の最終的な解決策ではない）に対してsuperを呼び出すように__getattr__メソッドを変更しましたが、ブレークポイントの問題はなくなったようです。問題を簡潔に定式化できる場合は、おそらくgoogle sqlalchemyニュースグループでさらに情報を入手するか、少なくともソリューションの堅牢性を確認しようとします。
Fabioのサポートに感謝します。trace_func（）関数が問題を特定してくれました。
本当に奇妙に思えます...問題をより適切に診断するために、さらに情報が必要です。
\ plugins\org.python.pydev.debug\pysrc\pydevd_constants.pyを開き、変更します
DEBUG_TRACE_LEVEL = 3
DEBUG_TRACE_BREAKPOINTS = 3
問題のあるユースケースを実行し、出力を質問に追加します...
また、何らかの理由で、使用しているライブラリまたはコードでデバッグ機能がリセットされている可能性があるため、次の手順を実行します。ブレークポイントを配置したのと同じ場所で実行します。
import sys
print 'current trace function', sys.gettrace()
（注：デバッガーで実行する場合、トレース関数は次のようになると予想されます：<bound method PyDB.trace_dispatch of <__main__.PyDB instance at 0x01D44878>>）
また、使用しているPythonバージョンを投稿してください。
回答パート2：
Sys.gettrace（）がNoneを返すという事実は、おそらく本当の問題です...私はそれを台無しにするいくつかの外部ライブラリを知っています（すなわち：DecoratorTools--read： http://pydev.blogspot.com/2007/06/why-cant-pydev-debugger-work-with.html ）そしてPythonバグとコンパイルされた拡張機能がそれを壊すのを見たことがあります...
それでも、それが壊れる最も一般的な理由は、おそらくPythonがサイレントにトレース（したがってデバッガー）を無効にするためです再帰がスタックオーバーフローエラーをスローしたとき（つまり、RuntimeError：最大再帰深度を超えました）。
プログラムの最初にブレークポイントを設定し、デバッガーが機能しなくなるまでステップインすることができます。
または、もっと簡単なのは次のとおりです。プログラムの最初に以下のコードを追加して、印刷がどの程度進むかを確認します...最後に印刷されるのは、壊れた直前のコードです（したがって、ブレークポイントを印刷される最後の行は、それが機能する最後の行である必要があることを認識しています）-大きなプログラムの場合、印刷に時間がかかる可能性があることに注意してください-コンソールではなくファイルへの印刷がさらに高速になる場合があります（ cmd、bash、またはEclipseとして）、後でそのファイルを開きます（例からファイルに印刷をリダイレクトするだけです）。
import sys
def trace_func(frame, event, arg):
print 'Context: ', frame.f_code.co_name, '\tFile:', frame.f_code.co_filename, '\tLine:', frame.f_lineno, '\tEvent:', event
return trace_func
sys.settrace(trace_func)
それでもわからない場合は、得られた結果の詳細を投稿してください...
注：実際の場所が使用されていることがわからなくなるまでの回避策：
import pydevd;pydevd.settrace()
ブレークポイントを配置する場所に-そうすれば、コードにブレークポイントがあり、その時点でトレース機能を強制的に設定するため、確実に機能するはずです（リモートデバッグと非常によく似ています：- http://pydev.org/manual_adv_remote_debugger.html ただし、デバッガーは既に接続されているため、リモートデバッガーを起動する必要はなく、ブレークポイントをエミュレートするためにsettraceを実行するだけです）
会話に遅れて来るが、それが助けになる場合に備えて。同様の問題が発生したところ、デバッガーが非常に特殊であることがわかりました。 「実行可能」と見なされ、中断できる行。
行継続または複数行式（リスト内など）を使用している場合は、ステートメントの最後の行にブレークポイントを設定します。
お役に立てば幸いです。
対応する.pycファイル（コンパイル済み）を削除してから実行してみてください。また、プログラムの複数のインスタンスを実行していることに気付くことがあります。これにより、pydevが混乱しました。私もこれを見たことがあります。かなりの回数。
似たような症状がありました。バイナリ（非Python）ライブラリを動的にロードする必要があるため、モジュールのインポートシーケンスがエントリポイントpythonモジュールをrexecしていることが判明しました。つまり、LD_LIBRARY_PATHが動的にリセットされました。これにより、デバッガーが後続のブレークポイントを無視する理由がわかりません。おそらく、rexec呼び出しはdebug = trueを指定しておらず、呼び出し元のコンテキスト状態に基づいてdebug = true/falseを指定する必要がありますか？
最初のインポートステートメントにブレークポイントを設定して、インポートをs（tep）するかn（ext）するかを認識してみてください。動的ライブラリのロードを必要とするサードパーティのインポートを「次に」実行すると、デバッグインタープリターはすべてのブレークポイントを超えて続行します。
Eclipse/pydevでDjangoアプリを実行している同様の状況に遭遇しました。実行されていたコードは、ソースコードではなく、virtualenvにインストールされたものでした。プロジェクトを削除しました。私の仮想環境サイトパッケージから、Eclipse/pydevデバッガーでDjangoを再起動し、すべてが正常でした。