Delphiのブレークポイント機能が失われることがあります。
これはDelphi 2009の問題だと思っていましたが、現在はDelphi XEでも発生しています。
Delphi 2009では、.dprojファイルを削除して、ブレークポイントを再び機能させました。
Delphi XEでは、ブレークピントを表示させることができません。すべてのホットフィックスが適用されたアップデート1があります。
誰かが解決策を持っていますか?
もっと良い方法を見つけました。
プロジェクトマネージャツリーでプロジェクトを右クリックし、ポップアップメニューから[クリーン]を選択します。
ブレークポイントは魔法のように再表示され、非常に高速な方法です。
ファイルにデバッグ情報がありません。
デバッグ構成を使用していることを確認してください。 (Project Manager
ツリー、Build Configurations
を展開し、Debug
が太字になっていることを確認します。太字でない場合は、Debug
を右クリックして、コンテキストメニューからActivate
を選択します。)次に、Compileだけでなく、プロジェクトのBuildを実行してください。
それでも機能しない場合は、IDEのメインメニューからProject->Options
に移動し、Delphi Compiler
の下のCompiling
をクリックして、右半分のDebugging
セクションを確認しますウィンドウの。 Debug Information
とLocal Symbols
の両方がチェックされていることを確認してください。 VCL自体のソースにトレースしようとしている場合は、Use debug .dcus
もチェックします(これをオフにして、プロジェクトが完了したらすぐにフルビルドを行います。通常デバッグしています)。繰り返しますが、コンパイルするのではなく、ビルドする必要があります。
上記のすべてが失敗する場合、別の可能性として、コードエディターで開いているコードユニットがコンパイラーで表示されているものと異なる可能性があります。コンパイラーが最初に検出する可能性のある場所にコンピューター上のファイルの複数のコピーがないことを確認してください。不明な場合は、そのユニット名の.dcuファイルを削除してからプロジェクトをビルドし、新しく作成した.dcuが予期した場所にあるかどうかを確認してください。
これは、デバッグを無効にしてリリースビルドを実行したときに発生すると思われます。次に、デバッグ構成に切り替えて、ビルドではなくコンパイルを行います。ブレークポイントを設定できないファイルは、デバッグを無効にしたコンパイルで生成されたDCUのファイルに対応しています。
すべてのDCUファイルを再生成するビルドを実行するだけで、ブレークポイントが再び機能します。
XE4でも同じ問題が発生しました。これが私がこの記事を数時間前に見つけた理由です。上記の解決策はどれも私にとってうまくいきませんでした。私にとっての正しい解決策-これまでは-「リモートデバッグシンボル」オプションを追加することでした。リモートデバッグを使用していないため、奇妙です。とにかく、今は大丈夫です。
ここで、コードとブレークポイントマーカー(ガターの青/赤の「ピル」)の位置がずれるもう1つの理由があります。
編集者は3つの異なる行末を認識し、
これらのうち、CRLF
がエディターのデフォルトです。
ただし、コンパイラーはCR only
を行末と見なさず、CRLF
とLF only
のみを考慮します。したがって、ソースファイルに1つ以上のCR only
がある場合、「青い丸薬」はソースからオフセットされます。
CR only
EOL(行末)文字を含むソースファイルを取得している可能性があります。インターネット。 EOSとしてCR only
を使用したMAC OSを思い出します。
ファイル内のEOLを確認するには、エディターでEOLの表示をオンにします
( Tools - Options - Editor options - Source options - Show line breaks)
。
記号は奇妙に見えますが(下の画像を参照)、CRLFの場合はLの上にC、CRの場合はRの上にC、LFの場合はFの上にLが表示されます。
次の画像は、16進エディタで1行にCR only
を強制し、別の行にLF only
を強制した後の通常のEOL(CRLF
)とEOLSを示しています。上記のように、ブレークポイントマーカーをソースコードからオフセットするのはCR only
です。
通常のCRLF
EOL:
CR only
を含む1行とLF only
を含む1行:
修正
すべてのEOLをCRLF
にリセットするには、Preserve line ends
のEditor Options
のチェックを外します
( Tools - Options - Editor options)
、
簡単な変更を加えて、ファイルが変更済みとしてマークされるようにし、ファイルを閉じ、変更をXYZ.pasに保存しますか? YES、再度開きます。
現在、すべての行末はCRLFです。プロジェクトを再構築すると、すべてのブレークポイントボールが正しい場所に配置されます。
リモートデバッグシンボルをオンにすると、それがうまくいきました(他には何も動作しませんでした)。 [プロジェクト]> [オプション]> [リンク]を選択し、[リモートデバッグシンボルを含める]をオンにします。
関連する問題がありました:特定のファイルのブレークポイントを失いましたが、他のファイルは問題ありませんでした。起こったことは、そのファイルの名前を変更したことですが、どこかで「uses」句で参照されていたため、古いファイルのDCUはまだ使用されていました。
解決策は、すべてのDCUを手動で削除し(「クリーン」を実行するだけでは不十分です。DCUで表される古いファイルがプロジェクトに存在しないため)、再構築します。不正な「uses」句を示すコンパイルエラーが発生します。
ブレークポイントが機能しないもう1つの理由は(delphi5でテストされることが多い)です。
ユニット内のプロシージャが多すぎます。
解決策は、手順を別のユニットに移動することです
ブレークポイントを設定しようとしているファイルがDLLの一部である場合は、プロジェクトマネージャーでそのファイルをダブルクリックしてDLLをアクティブにし、太字になってからビルドする必要があります。すると、ブレークポイントを設定できる行の横に青い円が表示されます。
ローカルPCへのリモートデバッグを試みます。
機能する理由:( source )
Delphiプロジェクトをローカルでデバッグする場合、RAD StudioはRSMデバッグファイルを使用しません。コンパイラがシンボルテーブルをメモリに保持しているためです。ただし、Delphiプロジェクトをリモートでデバッグする場合は、RSMデバッグを生成する必要があります。それらのシンボルテーブルを含むファイル、そうでない場合、RAD Studioはブレークポイントで停止しません。
もちろん、最初に* .rsmファイルを生成するには、プロジェクトの「リンク」オプションの「マップファイル」を「詳細」に設定する必要があります。開始方法については リモートデバッグの概要 を参照してください。
Delphi 7では、ブレークポイントの設定に実際のバグがあるようです。
私は多くのテキストが定義されているユニットを持っていました
const constname:array [0..x] of record-type =(...);
インターフェースセクションで、record-typeにいくつかのAnsiString項目があります。実装セクションでは、いくつかの手順があります。
特定のケースでは、プロシージャ内のどこかにブレークポイントを設定しても、delphiが停止しません。
備考:デバッグのすべてのオプションが適切に設定され(F7の場合、プログラムの「開始」でデルファイが停止するため、ユニット全体に青い点が表示され、アプリの実行中に線が赤のままになる)、PASファイルに一致するすべてのDCUプロジェクト全体を完全にビルドする前に、すべてのディスクとすべてのフォルダから削除されました。したがって、Woldファイルがどこにでも滞留することはありません。テストのために、PASの名前を別の名前に変更しました。これまでに使用したことがなく、ディスク上の他の場所にはないことを確認してから、すべてのソースを調整して再コンパイルしました。デルファイと私が同じPASファイルを見ていることを確認するためですが、ブレークポイントはどちらも機能しませんでした。
しかし、別の非常に奇妙なことが起こりました。テキストconsts(!)が実行可能ファイル内で変更されました(exeファイル内ではなく、明らかにメモリ内です)。これらのテキストは、プログラムの起動時に正しいかどうかがチェックされましたが、エラーが発生する場合がありました。メッセージボックス内のテキストの表示は、constとして定義されているそのテキスト内のsinlge文字が変更されたことを示しました。テストのために、コード内でそのconstsに何かを割り当てようとしましたが、予想どおり、コンパイラーが不平を言ったため、テキストの変更を引き起こすのは通常の割り当てではありません。間違ったポインタでなければなりません。変だ。
そのため、何時間ものテストが続き、後でテキストconstでその変更を引き起こす可能性がある間違ったポインタを設定した可能性のあるソースコードを探しました。ユニット初期化のチェーン内の最初のユニットの初期化セクションにメッセージボックスを配置しましたが、編集できましたが、変更された文字はすでにそこにありました!その場合、アプリケーションの起動時の非常に早い時期に変更する必要があります。
最後に、テキストに表示される文字は常に$ CCであることがわかりました。これは、INT3のアセンブラコードであり、delphiがブレークポイントの設定に使用しているコードです。また、そのユニット内のブレークポイントを1行上または下に移動すると、変更された文字の位置によって、一部の文字が左または右に移動します。また、間違った文字が移動した文字数は、関連する行に必要なアセンブラーでコーディングされたバイトの推定量と相関関係にあります。 2つのブレークポイントを行の近くに設定すると、2つの文字が突然変更されました。そのユニットからすべてのブレークポイントを削除しても、テキストは変更されませんでした。
つまり、結論は1つだけです。delphi自体が、ブレークポイントを設定しようとして失敗したときに、そのテキストを変更しています。私はこのバグを取り除くことができませんでした。 Delphiのソースとオブジェクトコードファイルの内部簿記を再同期することに関するヒントはどれも私を助けませんでした!
関係するユニットは主に複数の{$ IFDEF}間の{$ I}行で構成されていたため、異なるが長いPascalテキストを含むため、delphiのインクルージョンが長すぎるか、条件付きコンパイラディレクティブの評価に問題があると考えました。そこで、インクルードを削除し、ソーステキストをすぐにユニットに入れ、エラーなしでコンパイルされた{$ IFDEF}を削除しましたが、ブレークポイントを設定すると、実行を停止する代わりにテキスト定数も変更されました。すべて同じ!
今のところ、ユニットを2つのユニットに分割することでこれを解決しました。1つはインターフェース部分にテキストconstのみを保持し、もう1つは手順を保持します。そして今、コンパイラやリンカーの設定を変更しなくても、すべてのブレークポイントは期待どおりに機能し、テキストは変更されなくなりました。
したがって、ブレークポイントが機能しない場合は、機能するはずですが、デルファイが原因であり、ブレークポイントを正しい場所に設定できません。それがいくつかのテキストだけを変更している場合、それはおそらくあなたの注意を引くことはありません。ユニットを分割することは私を助けました、多分それもあなたを助けます。
私も同じ問題に直面していたので、ここに来ました。 David Heffernanソリューションに加えて、ここに画像を追加しています。私の場合、それはとても簡単でした。プロジェクトエクスプローラーでは、デバッグを変更したときにリリースでしたが、私にとってはうまくいきました。画像をご覧ください。
Happy Coding Iqbalに感謝
プロジェクトグループがパッケージ(BPL)を使用している場合は、暗黙的にインポートされたユニットに関するコンパイラの警告がないことを確認してください。これらが存在する場合、CPUデバッグウィンドウを介してのみコードをステップ実行できます。
私の場合、IDEで開いているときにユニットにブレークポイントを設定していましたが、現在アクティブなプロジェクトの一部ではありませんでした。そのようなブレークポイントも緑色で表示されます。IOWは右のページにいませんでしたまったく。
(私は上記のすべてを試した後にこれを発見しました。)
を使用して F9 アプリを実行するために、ブレークポイントは期待どおりに機能します。私はXE4を使用していますが、これが以前のバージョンのDelphiを「修正」するかどうかはわかりません。
少し遅い答えですが、私もこの問題につまずきました。
デバッグ構成を使用してプロジェクトマネージャーでMyPackage.bpl(太字)をアクティブ化し、それをコンパイルすると、IDEがデバッグ情報を登録したことがわかります(エディターの左側にある青い点)。
しかし、MainProject.exe(MyPackage.bplを使用するもの)をアクティブにすると、これらの青い点が消え、デバッグ情報が存在しないことを示します。頭をひっかいた後、デバッグ構成ではなくMyPackage.bplのリリース構成に依存関係(MainProject.exeを右クリック->依存関係)を設定したことに気付きました。
MyProject.exeをコンパイルするたびに、デバッグ構成ではなくリリース構成にリンクします。
依存関係の設定を確認してください!
DelphiコンパイルでMSBuildをチェックしました(MSビルドを行います)。これにより、ブレークポイントが機能しなくなりました。オフにすると動作します。