Eclipse - Haltepunkt kann aufgrund fehlender Zeilennummernattribute nicht installiert werden

Ich erhalte diesen seltsamen Fehler in Eclipse, wenn ich versuche, einen Haltepunkt festzulegen.

Unable to insert breakpoint Absent Line Number Information

Ich habe das Kontrollkästchen in den Compiler-Optionen aktiviert, aber kein Glück.

Ich hatte die gleiche Fehlermeldung in Eclipse 3.4.1, SUN JVM1.6.0_07, verbunden mit Tomcat 6.0 (im Debug-Modus auf einem anderen Computer, Sun JVM1.6.0_16, funktionierte die Debug-Verbindung korrekt).

Fenster -> Einstellungen -> Java -> Compiler -> Klassendateierzeugung: "Zeilennummernattribute zur generierten Klassendatei hinzufügen" wurde aktiviert. Ich habe eine saubere, neu kompilierte. Ich habe es deaktiviert, neu kompiliert, überprüft, neu kompiliert. Ich habe sichergestellt, dass das Projekt die globalen Einstellungen verwendet. Immer noch die gleiche Nachricht.

Ich wechselte zu Ant Build mit

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

Trotzdem die gleiche Nachricht.

Ich habe nicht herausgefunden, was diese Nachricht verursacht hat und warum sie nicht verschwindet. Obwohl es etwas mit der laufenden Tomcat-Debug-Sitzung zu tun zu haben schien: Wenn die Verbindung getrennt wird, wird das Problem durch erneutes Kompilieren behoben. Beim Verbinden des Debuggers mit Tomcat oder beim Festlegen neuer Haltepunkte während einer verbundenen Debug-Sitzung wurde dieser erneut angezeigt.

Es stellte sich jedoch heraus, dass die Meldung falsch war : Ich konnte tatsächlich vor und während des Debuggens Debugging- und Haltepunkte setzen ( javap -l zeigte auch Zeilennummern an). Also ignoriere es einfach :)

1. Gehen Sie im Eclipse-Menü zu Fenster-> Einstellungen-> Java-> Compiler
2. Deaktivieren Sie das Kontrollkästchen "Zeilennummernattribute hinzufügen ...".
3. Klicken Sie auf Übernehmen -> Ja
4. Aktivieren Sie das Kontrollkästchen "Zeilennummernattribut hinzufügen ..."
5. Bewerben Sie sich erneut.
6. Viel Spaß beim Debuggen

Dies hat mein Problem behoben:

1. Fenster -> Einstellungen -> Server -> Laufzeitumgebungen
2. Apache Tomcat -> bearbeiten
3. Wählen Sie ein JDK anstelle von JRE

Für Frühling damit zusammenhängende Fragen der Ansicht , dass es in einigen Fällen generieren Klassen „ohne Zeilennummern“; Wenn Sie beispielsweise eine @Servicekommentierte Klasse ohne Schnittstelle verwenden, fügen Sie die Schnittstelle hinzu, und Sie können debuggen. siehe hier für ein komplettes Beispiel.

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

Der obige Dienst verfügt über eine Schnittstelle, die durch die Feder generiert wird und "fehlende Zeilennummern" verursacht. Das Hinzufügen einer echten Schnittstelle löst das Generierungsproblem:

public interface TestService {
    void doSomething();
}

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

Ich habe die Antwort auf dieses Problem von der BlackBerry SDK-Seite: Aus irgendeinem Grund hat sich die zugrunde liegende Einstellungsdatei nicht geändert, unabhängig davon, wie oft ich die Optionen im Compiler geändert habe.

Suchen Sie im Ordner .settings Ihres Projekts nach einer Datei mit dem Namen org.eclipse.jdt.core.prefs .

Dort können Sie die Einstellungen manuell ändern:

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

edit: Außerdem habe ich festgestellt, dass ich manchmal die Warnung, die Eclipse ausgibt, ignorieren kann und sie immer noch an der gewünschten Stelle anhält ... Kurioser und Kurioser ... Ich habe dies in den Eimer mit Dingen gelegt, mit denen wir lernen, umzugehen bei der Arbeit als Entwickler.

Das hat bei mir funktioniert:

1. Unter Window --> Preferences --> Java --> Compiler --> Classfile Generationmüssen alle Optionen sein True.
2. Hergestellt debug="true"in der build.xml <javac>Aufgabe.
3. Stellen Sie die Anwendung im Tomcat durch den von Ant generierten Krieg bereit
4. Starten Sie den Tomcat im DebugModus neu

Ich weiß nicht, ob dies noch relevant ist, vielleicht findet es ein anderer Seemann nützlich.

Die Meldung wird angezeigt, wenn eine Klassendatei kompiliert wurde und die Debug-Flags deaktiviert sind.

In Eclipse können Sie es mit den oben genannten Optionen aktivieren:

Fenster -> Einstellungen -> Java -> Compiler -> Klassendateigenerierung: "Zeilennummernattribute zur generierten Klassendatei hinzufügen"

Wenn Sie jedoch eine JAR-Datei haben, erhalten Sie die kompilierte Ausgabe. Es gibt keine einfache Möglichkeit, dieses Problem zu beheben.

Wenn Sie Zugriff auf die Quelle haben und ant verwenden, um die JAR-Datei abzurufen, können Sie die ant-Aufgabe wie folgt ändern.

  <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"   >

Viel Spaß beim Debuggen ..

ref: http://doc.sumy.ua/prog/Java/javanut/ch16_04.htm

Ich habe hier fast jede Lösung ausprobiert und kein Glück. Haben Sie versucht, auf "Sag es mir nicht noch einmal" zu klicken? Danach habe ich mein Programm neu gestartet und alles war gut. Eclipse hat meinen Haltepunkt erreicht, als wäre nichts falsch.

Die Hauptursache für mich war, dass Eclipse versuchte, das Debuggen für automatisch generierte Spring CGLIB-Proxy-Objekte einzurichten. Sofern Sie auf dieser Ebene nichts debuggen müssen, sollten Sie das Problem ignorieren.

Es wäre hilfreich, wenn Sie die von Ihnen verwendete Eclipse-Version und die Technologie (z. B. Java JDT oder AJDT für Aspect Java oder C ++ CDT) angeben würden, nur um sicherzugehen.

Auf der Java - Seite, nehme ich Ihre „tickte das Kontrollkästchen von Compiler - Optionen“ bezieht sich auf diese

Unter " Window --> Preferences --> Java --> Compiler --> Classfile Generation" werden alle Class fileGenerierungsoptionen auf "Wahr" gesetzt:

• (1) Variablenattribute hinzufügen,
• (2) Addline-Nummern,
• (3) Quelldateinamen hinzufügen,
• (4) nicht verwendete lokale Variablen beibehalten.

Werden in Ihrem Projekt diese nur auf globaler Ebene (Windows-Einstellungen) oder auf projektspezifischer Ebene überprüft?

Und sind Sie sicher, dass die Klasse geöffnet wurde (für die Sie versuchen, einen Haltepunkt festzulegen):

• ist eine Ihrer Quellen (und stammt nicht aus einer Bibliothek eines Drittanbieters)
• ist ein .java, kein .class?

Versuchen Sie, alles zu bereinigen und alles neu zu erstellen, und suchen Sie nach möglichen JAR-Konflikten .

Ich hatte dieses Problem beim Versuch, Tomcat im Debugging-Modus von Eclipse aus zu starten. Ich hatte eine ANT-Build-Datei, die sich um das Kompilieren und Bereitstellen kümmerte. Nachdem das Debug-Flag auf true gesetzt wurde (wie in anderen Antworten erwähnt) und die Anwendung erneut bereitgestellt wurde, funktionierte es einwandfrei:

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

ANMERKUNG: Wenn Sie gerade das Debug-Flag hinzugefügt und neu kompiliert haben, müssen Sie Ihre Anwendung dennoch erneut auf dem Server bereitstellen , da Eclipse hier die Klassendateien debuggt. Sehr offensichtlich, aber leicht eine Stunde oder so damit zu verbringen, sich am Kopf zu kratzen und sich zu fragen, warum es nicht funktioniert (vertrau mir).

Versuchen Sie, die von jreIhnen verwendete zu ändern. Legen Sie die jrein den Ordner von JDKstattdessen.

Da ich 6 verschiedene Java-Versionen installiert habe, musste ich meine Standard-JDK-Konformität ändern, um sie an die Java-Version anzupassen, die ich verwenden wollte. Bei Eclipse wurde die Compiler-Konformitätsstufe standardmäßig auf Java 1.7 festgelegt, als alles mit Java 1.6 erstellt / kompiliert wurde.

Also war alles was ich tat

1. Gehen Sie im Eclipse-Menü zu Fenster-> Einstellungen-> Java-> Compiler
2. Unter JDK-Konformität habe ich die Compiler-Konformitätsstufe von 1,7 auf 1,6 geändert

Jetzt beschwert sich Eclipse nicht mehr über die Meldung "Haltepunkt-Abwesenheitsnummer kann nicht eingefügt werden" und die Debugging-Haltepunkte funktionieren tatsächlich !!!

Wenn nichts anderes funktioniert, öffnen Sie die Debug-Perspektive, löschen Sie alle vorhandenen Haltepunkte und setzen Sie sie erneut zurück.

Dies wird hier ausführlich erklärt:

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

Nur zum späteren Nachschlagen ist dies der relevante Teil der Antwort (ignorieren Sie die Tatsache, dass auf eine Spring Boot-Anwendung verwiesen wird, das Verhalten ist in vielen anderen Fällen das gleiche):

Immer wenn Sie in Eclipse / STS einen Haltepunkt festlegen, versucht die IDE, den Haltepunkt in der VM festzulegen, wenn Sie eine App starten. Dies passiert in Ihrem Fall, wenn Sie die Boot-App im Debug-Modus ausführen.

Für jede Klasse, die in die JVM geladen wird, prüft die IDE, ob ein Haltepunkt festgelegt werden muss oder nicht. Wenn der Haltepunkt festgelegt wird, wird dies versucht (unter Verwendung der Informationen aus der Haltepunktdefinition in der IDE, einschließlich der Zeilennummer, da Sie normalerweise Zeilenumbruchpunkte in einer Quelldatei in einer bestimmten Zeile festlegen).

Diese Entscheidung (ob der Haltepunkt für eine bestimmte geladene Klasse festgelegt werden soll oder nicht) überprüft die Typen, für die Sie den Haltepunkt festgelegt haben, einschließlich Typen und innerer Klassen. Dadurch wird sichergestellt, dass Haltepunkte für innere Klassen (auch anonyme innere Klassen) auf die JVM gesetzt werden (und nicht ignoriert werden).

Spring Boot generiert zur Laufzeit eine innere Klasse für Ihren Controller (dies ist die von CGLIB generierte innere Klasse, die in der Fehlermeldung angezeigt wird). Wenn die JVM diese Klasse lädt, versucht sie, den Zeilennummern-Haltepunkt des umschließenden Typs (für diese innere Klasse) festzulegen. Da die generierte innere Klasse keine Zeilennummerninformationen enthält (sie muss keine Zeilennummerninformationen enthalten), schlägt das Festlegen des Haltepunkts für diese innere Klasse mit der genannten Fehlermeldung fehl.

Wenn die IDE den umschließenden Typ (Ihre Controller-Klasse selbst) lädt, versucht sie auch, den Zeilenumbruchpunkt festzulegen, und ist damit erfolgreich. Dies wird mit der Prüfmarkierung auf der Haltepunktmarkierung visualisiert.

Daher können Sie die angezeigte Fehlermeldung ignorieren. Um zu vermeiden, dass diese Fehlermeldung angezeigt wird, können Sie zu den Einstellungen (Java -> Debug) gehen und "Warnen, wenn der Haltepunkt aufgrund fehlender Zeilennummernattribute nicht installiert werden kann" deaktivieren.

Meine Situation war ähnlich:

• Ich habe einen JUnit-Test getestet
• Ich habe Mockito benutzt, um einen Spion zu erschaffen, wie in spyTask = spy(new Task())
• Ich habe den Haltepunkt in die Klasse eingefügt, die ich ausspioniert habe (innerhalb Task.java)

Dieser Haltepunkt generiert bei jeder Ausführung den betreffenden Fehler Debug As... > JUnit Test

Um das Problem zu beheben, habe ich den Haltepunkt in den eigentlichen Test (in TaskTest.java) verschoben. Sobald die Ausführung gestoppt war, fügte ich den Haltepunkt an der Stelle hinzu, an der ich ihn ursprünglich hatte (in Task.java).

Ich habe immer noch den gleichen Fehler erhalten, aber nachdem ich auf "OK" geklickt habe, hat der Haltepunkt einwandfrei funktioniert.

Hoffe das hilft jemandem,

-gmale

Ich hatte das gleiche Problem, als ich auf einem Anlegestellen-Server eine neue .war-Datei von ANT kompilierte. Sie sollten dieselbe Version des jdk / jre-Compilers und des Erstellungspfads (z. B. jdk 1.6v33, jdk 1.7, ....) erstellen, nachdem Sie den Java-Compiler wie zuvor beschrieben festlegen müssen.

Ich habe alles gemacht und immer noch nicht gearbeitet. Die Lösung bestand darin, die kompilierten .class-Dateien und das Ziel der generierten Kriegsdatei zu löschen und jetzt funktioniert es :)

Ich habe diese Nachricht mit Spring AOP erhalten (scheint aus der CGLIB-Bibliothek zu stammen). Das Klicken auf Ignorieren scheint gut zu funktionieren, ich kann trotzdem debuggen.

Ich habe noch einen weiteren Grund für diese Nachricht gefunden. Ich habe Scala programmiert. Die Lösung war:

1. Öffnen Sie Ausführen -> Debug-Konfigurationen
2. Auf der Registerkarte "Haupt" unten neben den Schaltflächen "Übernehmen" und "Zurücksetzen" befindet sich ein Text, der angibt, welchen Launcher Sie verwenden, und daneben ein Hyperlink mit der Aufschrift "Andere auswählen". Es ist ein seltsames UI-Element, das auf den ersten Blick nicht umsetzbar aussieht.
3. Verwenden Sie den Link "Andere auswählen" und wählen Sie "Scala Application (neuer Debugger) Launcher". Der andere scheint nicht mit Scala zu arbeiten.

Jetzt sollte das Debuggen funktionieren. Beachten Sie, dass ich das Scala IDE-Plugin installiert habe. Diese Option ist möglicherweise nicht verfügbar, wenn Sie sie nicht haben.

Oben haben die Dinge bei mir nicht funktioniert. Die folgenden Lösungen haben endlich funktioniert. Debug-Konfigurationen -> Klassenpfad -> Benutzereinträge -> (Fügen Sie den Ordner src des Projekts hinzu, das Sie debuggen möchten.)

Ich hatte das gleiche Problem beim Debuggen eines WAR (das aus mehreren Eclipse-Projektartefakten erstellt wurde), das in Tomcat bereitgestellt wurde.

Ich baue alles mit einem ANT-Build-Skript. Wenn Sie dies tun, stellen Sie sicher, dass das Flag debug = true für jede Javac Ant-Aufgabe gesetzt ist, die Sie haben. Dies war mein einziges Problem - ich hoffe, es hilft Ihrem Problem!

Ich hatte den gleichen Fehler mit JBoss 7.1. Und ich tat das gleiche wie Zefiro. Ich habe den Fehler einfach ignoriert und konnte Haltepunkte normal platzieren. In meinem Fall habe ich Gedankenameisenbauer gebaut und das ist meine Javac-Aufgabe:

<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>

Ich habe das gleiche Problem, ich habe viel Zeit damit verbracht, nach einer Lösung zu suchen, aber diese Lösungen sind nicht sinnvoll. Also habe ich alle Fälle selbst studiert und schließlich herausgefunden, dass es sich um einen Konflikt zwischen JDK-Versionen handelt. Im Folgenden finden Sie Schritte zur Behebung des Problems: 1. Entfernen Sie alle JDK- und JRE-Versionen. Behalten Sie nur eine Version bei. 2. Stellen Sie das JAVA_HOME-System und den Java-Compiler in Eclipse ein. In einigen Fällen verschwindet der obige Fehler nicht, aber wir können das Debug-Modell ausführen.

Als ich den gleichen Fehler bei der Verwendung von junit und Mockito hatte, vergaß ich, ihn hinzuzufügen @PrepareForTest eine statische Klasse .

Der folgende Code hat mein Problem behoben.

@PrepareForTest({XXXXX.class})

_{Ich bin mir nicht sicher, ob es der gleiche Fall war.}

Mein Problem war, dass ich 2 JARs hatte und versuchte, eine mit der anderen zu überschreiben, basierend auf der Reihenfolge in der Java Build Path => Order & Export Registerkarte in Eclipse , da eine für das Debuggen war und die andere nicht (die Debugging-JAR war die erste in der Reihenfolge). Wenn ich es so machte, musste ich eine Quelle manuell anhängen.

Ich habe versucht, die Nicht-Debug-JAR zu entfernen und die Debug-JAR in meinem Verzeichnis \ WEB-INF \ lib \ abzulegen, zu reinigen, zu erstellen usw., und es hat funktioniert. Dieses Mal (nachdem ich die angehängte Quelle entfernt hatte) konnte ich automatisch durch den Debug-Code navigieren, ohne eine Quelle manuell anhängen zu müssen. Haltepunkte und Debugging funktionierten ebenfalls.

Falls noch jemand Probleme hat, habe ich auch alle diese speziellen Lösungen ausprobiert, die in den anderen Antworten erwähnt werden:

• Deaktivieren, anwenden und erneut aktivieren Add line number attributes...
• Manuelles Bearbeiten org.eclipse.jdt.core.prefswie in einer anderen Antwort erwähnt: https://stackoverflow.com/a/31588700/1599699
• Sicherstellen, dass die JAR mit aktiviertem Debug generiert wurde.
• Ändern der JDK-Konformitätsstufe von 1,6 auf 1,7 (damit entspricht sie dem von mir verwendeten JDK).

Ich habe auch das übliche Herunterfahren des Servers durchgeführt (und sichergestellt, dass java.exe tatsächlich geschlossen ist ...), die Verzeichnisse \ build \ in beiden Projekten gelöscht, Eclipse mit dem Parameter -clean neu gestartet, die Debug-JAR neu erstellt, aktualisiert, Bereinigen und Erstellen des Projekts mit der darin enthaltenen Debug-JAR, Starten des Servers im Debug-Modus, Veröffentlichen / Bereinigen und Haltepunkt.

Ich habe alles getan, was oben aufgeführt ist, während ich die Gläser zusammengestellt / gebaut habe - hatte immer noch das gleiche Problem.

Schließlich haben die unten aufgeführten jvmarg-Änderungen beim Starten des Servers für mich endlich funktioniert:

1) Eine Reihe von JVM-Argumenten für Javaagent und Bootclasspath wurden entfernt / kommentiert.

2) Die folgende Zeile aktiviert / nicht kommentiert:

Wenn ich dann den Server starte, kann ich meine Haltepunkte erreichen. Ich vermute, dass der Javaagent die Fähigkeit von Eclipse, Zeilennummern zu erkennen, irgendwie beeinträchtigt hat.

Überprüfen / tun Sie Folgendes:

1) Unter "Fenster -> Einstellungen -> Java -> Compiler -> Generierung von Klassendateien" müssen alle Optionen auf True stehen:

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

2) Suchen Sie im Ordner .settings Ihres Projekts nach einer Datei mit dem Namen org.eclipse.jdt.core.prefs. Überprüfen oder setzen Sie org.eclipse.jdt.core.compiler.debug.lineNumber = generate

3) Wenn das Fehlerfenster weiterhin angezeigt wird, aktivieren Sie das Kontrollkästchen, um die Fehlermeldung nicht anzuzeigen.

4) Reinigen und bauen Sie das Projekt. Starten Sie das Debuggen.

Normalerweise wird das Fehlerfenster nicht mehr angezeigt und die Debugging-Informationen werden korrekt angezeigt.

Ich bin auch auf dieses Problem gestoßen. Ich verwende ein Ameisen-Build-Skript. Ich arbeite an einer Legacy-Anwendung, daher verwende ich JDK Version 1.4.2. Das hat früher funktioniert, also habe ich mich umgesehen. Ich habe festgestellt, dass unter der Debug-Konfiguration auf der Registerkarte JRE die Java-Version auf 1.7 eingestellt war. Sobald ich es wieder auf 1.4 geändert habe, hat es funktioniert.

Ich hoffe das hilft.

Ich habe versucht, den Protokollierungsmanager zu debuggen, und musste das jre in ein jdk ändern und dann dieses jdk auf der Registerkarte "main", "Java Runtime Environment" | auswählen "Laufzeit JRE" der Debug-Konfiguration dann war alles in Ordnung.

Ich habe dieses Problem gesehen, als ich eine Klasse mit @ManagedBean (javax.annotation.ManagedBean) kommentiert habe. Die Warnmeldung wurde angezeigt, wenn die neu erfüllte App auf JBoss EAP 6.2.0 ausgeführt wurde. Es zu ignorieren und trotzdem zu laufen half nicht - der Haltepunkt wurde nie erreicht.

Ich habe diese Bean mit EL auf einer JSF-Seite aufgerufen. Nun ... es ist möglich, dass @ManagedBean dafür nicht gut ist (ich bin neu bei CDI). Als ich meine Annotation in @Model änderte, wurde meine Bean ausgeführt, aber die Haltepunktwarnung verschwand ebenfalls und ich traf den Haltepunkt wie erwartet.

Zusammenfassend sah es sicherlich so aus, als ob die Annotation @ManagedBean die Zeilennummern durcheinander gebracht hätte, unabhängig davon, ob es sich um die falsche Annotation handelte oder nicht.

Stellen Sie sicher, dass das Projekt, in dem sich die Hauptklasse der Laufzeit befindet, dasselbe Projekt ist, in dem sich die Klasse befindet, in der Sie Haltepunkte haben . Wenn nicht, stellen Sie sicher, dass sich beide Projekte im Klassenpfad der Ausführungskonfiguration befinden und vor allen Jars und Klassenordnern angezeigt werden.