Eclipse-行番号属性がないためにブレークポイントをインストールできません

ブレークポイントを設定しようとすると、Eclipseでこの奇妙なエラーが発生します。

Unable to insert breakpoint Absent Line Number Information

コンパイラオプションのチェックボックスをオンにしましたが、うまくいきませんでした。

Eclipse 3.4.1で同じエラーメッセージが表示され、SUN JVM1.6.0_07がTomcat 6.0に接続されました（別のマシンのデバッグモードで実行されているSun JVM1.6.0_16、デバッグ接続は正しく機能していました）。

ウィンドウ->設定-> Java->コンパイラ->クラスファイルの生成：「生成されたクラスファイルに行番号属性を追加」がチェックされました。クリーンで再コンパイルしました。チェックを外し、再コンパイルし、チェックし、再コンパイルしました。プロジェクトがグローバル設定を使用することを確認しました。まだ同じメッセージ。

私はアリビルドに切り替えて、

<javac srcdir="./src/java" destdir="./bin" debug="true">

それでも、同じメッセージ。

このメッセージの原因とそれが消えない理由はわかりませんでした。実行中のTomcatデバッグセッションと関係があるように見えましたが、切断されたときに再コンパイルすると問題が解決します。しかし、デバッガーをTomcatに接続するか、接続されたデバッグセッション中に新しいブレークポイントを設定すると、再び表示されました。

ただし、メッセージが間違っていることがわかりました。デバッグの前とデバッグ中に、実際にデバッグとブレークポイントの設定ができました（javap -lでも行番号が表示されました）。だからそれを無視してください:)

1. Eclipseメニューで、[ウィンドウ]-> [設定]-> [Java]-> [コンパイラ]に移動します。
2. 「行番号属性を追加...」チェックボックスをオフにします
3. [適用]-> [はい]をクリックします
4. 「行番号属性を追加...」チェックボックスをマークします
5. 再度お申し込みください。
6. デバッグを楽しんでください

これは私の問題を修正しました：

1. ウィンドウ->設定->サーバー->ランタイム環境
2. Apache Tomcat->編集
3. JREの代わりにJDKを選択する

以下のために春に関連する問題は、いくつかのケースでは、「行番号なし」クラスを生成することを検討してください。たとえば、@Serviceインターフェースのない注釈付きクラスの場合は、インターフェースを追加してデバッグできます。完全な例については、こちらをご覧ください。

@Service("SkillService")
public class TestServiceWithoutInterface {
   public void doSomething() {
      System.out.println("Hello TestServiceWithoutInterface");
   }
}

上記のサービスには、「行番号の欠落」を引き起こすSpringによって生成されたインターフェースがあります。実際のインターフェースを追加すると、生成の問題が解決します。

public interface TestService {
    void doSomething();
}

@Service("SkillService")
public class TestServiceImpl implements TestService {
   public void doSomething() {
      System.out.println("Hello TestServiceImpl");
   }
}

私はBlackBerry SDK側からこの問題に答えています。何らかの理由で、コンパイラーのオプションを何度変更しても、実際の基本設定ファイルは変更されませんでした。

プロジェクトの.settingsフォルダーでorg.eclipse.jdt.core.prefsというファイルを探します。

そこで手動で設定を変更できます：

org.eclipse.jdt.core.compiler.debug.lineNumber=generate

編集：これに加えて、私は時々私はEclipseが与える警告を無視できることに気づきました、そしてそれはまだ必要な場所で止まります... curioserとcurioser ...私はこれを私たちが対処することを学ぶもののバケットに入れました開発者として働いているとき。

これは私のために働きました：

1. の下ではWindow --> Preferences --> Java --> Compiler --> Classfile Generation、すべてのオプションをにする必要がありTrueます。
2. メイドdebug="true"のbuild.xmlで<javac>タスク。
3. Antによって生成された戦争によってTomcatにアプリケーションをデプロイする
4. DebugモードでTomcatを再起動しました

これがまだ関連があるかどうかわからない、おそらく別の船乗りがこれが役立つと思うでしょう。

クラスファイルをコンパイルしてデバッグフラグをオフにすると、メッセージが表示されます。

日食では、前述のオプションでオンにすることができます。

ウィンドウ->設定-> Java->コンパイラ->クラスファイルの生成：「生成されたクラスファイルに行番号属性を追加」

しかし、jarファイルがある場合は、コンパイルされた出力が得られます。この問題を簡単に修正する方法はありません。

ソースにアクセスでき、antを使用してjarファイルを取得する場合は、antタスクを次のように変更できます。

  <javac  destdir="${build.destDir}" srcdir="${build.srcDir}" source="1.6" fork="true" target="${javac.target}" debug="on" debuglevel="lines,vars,source" deprecation="on" memoryInitialSize="512m" memoryMaximumSize="1024m" optimize="true"   >

幸せなデバッグ。

参照：http : //doc.sumy.ua/prog/Java/javanut/ch16_04.htm

私はここでほとんどすべての解決策を試しましたが、運はありませんでした。 「もう教えない」をクリックしてみましたか？ そうした後、私はプログラムを再起動し、すべてが順調でした。Eclipseは何も問題がなかったかのように私のブレークポイントにぶつかりました。

私の根本的な原因は、Eclipseが自動生成されたSpring CGLIBプロキシオブジェクトのデバッグをセットアップしようとしていたことです。そのレベルで何かをデバッグする必要がない限り、問題は無視してください。

念のため、使用しているEclipseのバージョンとテクノロジ（Java JDT、またはAspect Javaの場合はAJDT、またはC ++ CDTなど）を示した場合に役立ちます。

Java側では、「コンパイラオプションのチェックボックスをオンにした」がこれを参照していると思います

「Window --> Preferences --> Java --> Compiler --> Classfile Generation」では、すべての「Class file」生成オプションがTrueに設定されています。

• （1）変数属性を追加し、
• （2）アドライン番号、
• （3）ソースファイル名を追加し、
• （4）未使用のローカル変数を保持します。

あなたのプロジェクトでは、グローバルレベル（Windowsの設定）またはプロジェクト固有のレベルでのみチェックが行われていますか？

そして、クラスが開かれていることを確認します（ブレークポイントを設定しようとしています）：

• ソースの1つです（サードパーティのライブラリからのものではありません）
• で.java、ではありませんか.class？

すべてをクリーンアップしてすべてを再構築し、jarの競合の可能性をチェックしてください。

EclipseからデバッグモードでTomcatを起動しようとしたときに、この問題が発生しました。コンパイルとデプロイを処理するANTビルドファイルがありました。（他の回答で述べたように）デバッグフラグをtrueに設定し、アプリケーションを再デプロイした後、正常に機能しました。

<javac srcdir="./src/java" destdir="./bin" debug="true">

注：デバッグフラグを追加して再コンパイルしたばかりの場合でも、Eclipseがクラスファイルをデバッグしているので、アプリケーションをサーバーに再デプロイする必要があります。非常に明白ですが、1時間ほど費やすのは簡単ですが、頭をかいて、なぜ機能しないのか疑問に思います（信頼してください）。

変更しようとjreあなたがuse.Set jreのフォルダにJDK代わりに。

私は6つの異なるバージョンのJavaをインストールしているので、使用したいJavaバージョンのJDK準拠に合わせてデフォルトのJDK準拠を変更する必要がありました。すべてがJava 1.6を使用してビルド/コンパイルされた場合、Eclipseのデフォルトではコンパイラー準拠レベルがJava 1.7に設定されていました。

だから私がしたことは

1. Eclipseメニューで、[ウィンドウ]-> [設定]-> [Java]-> [コンパイラ]に移動します。
2. JDKコンプライアンスの下で、コンパイラーのコンプライアンスレベルを1.7から1.6に変更しました

これで、Eclipseは「ブレークポイントが存在しないため、行番号情報を挿入できません」というメッセージを表示しなくなり、デバッグブレークポイントは実際に機能します!!!

他に何も機能しない場合は、デバッグパースペクティブを開き、既存のブレークポイントをすべてクリアしてから、再度設定し直してください。

これはここで詳しく説明されています：

https://github.com/spring-projects/spring-ide/issues/78

将来の参考のために、これは回答の関連部分です（Spring Bootアプリケーションを参照するという事実を無視して、動作は他の多くの場合と同じです）：

Eclipse / STSでブレークポイントを設定すると、アプリを起動するとIDEがVMにブレークポイントを設定しようとします。これが、デバッグモードでブートアプリを実行した場合に起こります。

IDEは、JVMに読み込まれるクラスごとに、ブレークポイントを設定する必要があるかどうかを確認します。ブレークポイントを設定すると決定した場合、は設定を試みます（IDEのブレークポイント定義からの情報を使用します。通常、ソースファイルの特定の行に行ブレークポイントを設定するため、その行番号を含みます）。

この決定（特定のロードされたクラスにブレークポイントを設定するかどうか）は、ブレークポイントを設定した型、それを囲む型、および内部クラスをチェックします。これにより、内部クラス（匿名の内部クラスも含む）のブレークポイントがJVMに設定されます（無視されません）。

Spring Bootは、実行時にコントローラーの内部クラスを生成します（これは、エラーメッセージに表示されるCGLIB生成の内部クラスです）。JVMがそのクラスをロードするとき、JVMは（この内部クラスの）囲んでいるタイプの行番号ブレークポイントを設定しようとします。生成された内部クラスには行番号情報がないため（行番号情報を持つ必要はありません）、この内部クラスのブレークポイントの設定は、前述のエラーメッセージで失敗します。

IDEが囲んでいるタイプ（コントローラクラス自体）をロードすると、行ブレークポイントの設定も試行され、成功します。これは、ブレークポイントマーカーのチェックマーカーで視覚化されます。

したがって、表示されるエラーメッセージは無視しても問題ありません。このエラーメッセージが表示されないようにするには、設定（Java->デバッグ）に移動し、「行番号属性がないためにブレークポイントをインストールできないときに警告する」を無効にします。

私の状況は似ていました：

• JUnitテストをデバッグしていた
• 私はモッキートを使ってスパイを作成していました。 spyTask = spy(new Task())
• スパイしているクラスの内側にブレークポイントを配置しました（内部Task.java）

このブレークポイントは、実行するたびに問題のエラーを生成します Debug As... > JUnit Test

この問題に対処するために、ブレークポイントを実際のテスト（TaskTest.java内）に移動しました。実行が停止したら、ブレークポイントを元の場所（Task.java内）に戻しました。

引き続き同じエラーが発生しますが、[OK]をクリックした後、ブレークポイントは正常に機能しました。

それが誰かを助けることを願って、

-gmale

jettyサーバーで作成し、ANTで新しい.warファイルをコンパイルするときにも同じ問題が発生しました。以前に記述したようにJavaコンパイラを設定する必要がある場合は、同じバージョンのjdk / jreコンパイラとビルドパス（たとえば、jdk 1.6v33、jdk 1.7、...）を作成する必要があります。

私はすべてをやったが、まだ働いていません。解決策は、コンパイルされた.classファイルと生成されたwarファイルのターゲットを削除し、現在はその機能です:)

Spring AOPでこのメッセージを受け取りました（CGLIBライブラリから送信されているようです）。[無視]をクリックしても問題なく動作するようですが、デバッグは可能です。

このメッセージのさらに別の理由を見つけました。私はScalaをプログラミングしていました。解決策は：

1. Open Run-> Debug設定
2. メインタブの下部にある「適用」ボタンと「元に戻す」ボタンの横に、使用しているランチャーを示すテキストがあり、その横に「他を選択」というハイパーリンクがあります。これは奇妙なUI要素であり、一見すると実行可能ではないように見えます。
3. [他を選択]リンクを使用して、[Scalaアプリケーション（新しいデバッガー）ランチャー]を選択します。もう1つはScalaで動作しないようです。

これでデバッグが機能するはずです。Scala IDEプラグインをインストールしたことに注意してください。このオプションがない場合、このオプションを使用できない場合があります。

上記のことは私にはうまくいきませんでした。以下のソリューションは最終的に機能しました。デバッグ構成->クラスパス->ユーザーエントリ->（デバッグするプロジェクトのsrcフォルダーを追加します。）

TomcatにデプロイされたWAR（複数のEclipseプロジェクトアーティファクトから構築された）をデバッグするときにも同じ問題が発生しました。

ANTビルドスクリプトを使用してすべてをビルドしています。これがあなたのやっていることであるなら、あなたが得たすべてのjavac antタスクでdebug = trueフラグが設定されていることを確認してください。これが私の唯一の問題でした。問題が解決することを願っています。

JBoss 7.1でも同じエラーが発生しました。Zefiroでも同じエラーが発生しました。エラーを無視して、ブレークポイントを通常どおりに配置できました。私の場合、私は思考antビルダーを構築しており、これは私のjavacタスクです：

<javac
        srcdir="${src.dir}"
        destdir="${build.classes.dir}" 
        includeantruntime="false" 
        debug="${debug}"
        verbose="false"
        debuglevel="lines,vars,source"
        source="1.6"
        target="1.6">

        <!-- Sppressing warning for setting an older source without bootclasspath
             (see: https://blogs.oracle.com/darcy/entry/bootclasspath_older_source) -->
        <compilerarg value="-Xlint:-options"/>

        <classpath>
            <fileset dir="${lib.dir}" includes="*.jar" />
            <fileset dir="${jboss.lib.dir}" includes="**/*.jar" />
        </classpath>

    </javac>

同じ問題が発生し、解決策を探すために多くの時間を費やしましたが、これらの解決策は役に立たないので、すべてのケースを自己調査し、最終的に、JDKバージョン間の競合であるという問題を発見しました。以下は、問題を解決する手順です。1. JDKおよびJREバージョンをすべて削除し、1つのバージョンのみを保持します。2. EclipseでのJAVA_HOMEシステムとJavaコンパイラの設定は同じです。場合によっては、上記のエラーが消えないことがありますが、デバッグモデルで実行できます。

junitとMockitoを使用したときに同じエラーが発生した後、追加するのを忘れました @PrepareForTest、静的クラスました。

以下のコードを追加して問題を修正しました。

@PrepareForTest({XXXXX.class})

_{同じケースだったかどうかはわかりません。}

私の問題は、2つのJARがあり、 Java Build Path => Order & Export、Eclipseタブの。このようにすると、手動でソースを接続する必要がありました。

非デバッグJARを削除して、デバッグJARを\ WEB-INF \ lib \ディレクトリに配置し、クリーニング、ビルドなどを試みましたが、うまくいきました。今回は（アタッチされたソースを削除した）、ソースを手動でアタッチしなくても、デバッグコードを自動的にナビゲートできます。ブレークポイントとデバッグも機能しました。

誰かがまだ問題を抱えている場合に備えて、私は他の回答で言及されているこれらの特定の解決策もすべて試しました：

• チェックを外し、適用し、再確認します Add line number attributes...
• org.eclipse.jdt.core.prefs別の回答で述べられているように手動で編集する：https : //stackoverflow.com/a/31588700/1599699
• デバッグを有効にしてJARが生成されていることを確認します。
• JDK準拠レベルを1.6から1.7に変更します（これにより、使用していたJDKと一致します）。

また、サーバーの通常のシャットダウン（およびjava.exeが実際に閉じられていることを確認）、両方のプロジェクトの\ build \ディレクトリの削除、-cleanパラメーターを使用したEclipseの再起動、デバッグJARの再作成、更新、クリーニング、デバッグJARを含むプロジェクトのビルド、サーバーのデバッグモードでの起動、公開/クリーニング、ブレークポイント。

jarのコンパイル/ビルド中に上記のすべてを実行しましたが、同じ問題がまだありました。

最終的には、サーバーの起動中に以下にリストするjvmargの変更が、最終的に私にとってうまくいきました。

1）javaagentおよびbootclasspathに関連する一連のjvm引数を削除/コメントしました。

2）次の行をオン/コメント解除：

その後、サーバーを起動すると、ブレークポイントに到達できます。javaagentがEclipseの行番号を検出する機能を何らかの形で妨害していると思います。

以下を確認/実行します。

1）[ウィンドウ->設定-> Java->コンパイラ->クラスファイルの生成]で、すべてのオプションをTrueにする必要があります。

(1) Add variable attributes...
(2) Add line number attributes...
(3) Add source file name...
(4) Preserve unused (never read) local variables

2）プロジェクトの.settingsフォルダーで、org.eclipse.jdt.core.prefsというファイルを探します。org.eclipse.jdt.core.compiler.debug.lineNumber = generateを確認または設定します

3）それでもエラーウィンドウが表示される場合は、チェックボックスをクリックしてエラーメッセージを表示しないようにします。

4）プロジェクトをクリーンアップしてビルドします。デバッグを開始します。

通常、エラーウィンドウは表示されなくなり、デバッグ情報が正しく表示されます。

私もこの問題に遭遇しました。Antビルドスクリプトを使用しています。レガシーアプリケーションに取り組んでいるため、jdkバージョン1.4.2を使用しています。これは以前は機能していたので、周りを探し始めました。「JRE」タブの「デバッグ構成」で、Javaのバージョンが1.7に設定されていることに気付きました。1.4に戻すと、問題なく動作しました。

これがお役に立てば幸いです。

ロギングマネージャーをデバッグしようとしていて、jreをjdkに変更してから、「メイン」タブの「Javaランタイム環境」でこのjdkを選択する必要がありました。デバッグ構成の「ランタイムJRE」であれば、すべて順調でした。

@ManagedBean（javax.annotation.ManagedBean）でクラスに注釈を付けると、この問題が発生しました。JBoss EAP 6.2.0で新しくコンパイルされたアプリを実行すると警告メッセージが表示されました。それを無視して実行しても効果はありませんでした。ブレークポイントに到達することはありませんでした。

JSFページでELを使用してそのBeanを呼び出していました。さて... @ManagedBeanはそれでは役に立たない可能性があります（CDIは初めてです）。アノテーションを@Modelに変更すると、Beanが実行されましたが、ブレークポイントの警告も消え、期待どおりにブレークポイントにヒットしました。

要約すると、使用するアノテーションが間違っているかどうかに関係なく、@ ManagedBeanアノテーションが行番号を台無しにしたように見えました。

ランタイムのメインクラスがあるプロジェクトが、ブレークポイントを持っているクラスと同じプロジェクトであることを確認してください。そうでない場合は、両方のプロジェクトが実行構成のクラスパスにあり、jarおよびクラスフォルダーの前にあることを確認してください。