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.
eclipse
debugging
breakpoints
chandrajeet
quelle
quelle
Antworten:
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
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 :)
quelle
debug="true"
zurjavac
Aufgabe desant
Build-Skripts hat funktioniert.quelle
Dies hat mein Problem behoben:
quelle
Installed JREs
JDK
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
@Service
kommentierte Klasse ohne Schnittstelle verwenden, fügen Sie die Schnittstelle hinzu, und Sie können debuggen. siehe hier für ein komplettes Beispiel.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:
quelle
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:
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.
quelle
Das hat bei mir funktioniert:
Window --> Preferences --> Java --> Compiler --> Classfile Generation
müssen alle Optionen seinTrue
.debug="true"
in der build.xml<javac>
Aufgabe.Debug
Modus neuquelle
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.
Viel Spaß beim Debuggen ..
ref: http://doc.sumy.ua/prog/Java/javanut/ch16_04.htm
quelle
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.
quelle
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 alleClass file
Generierungsoptionen auf "Wahr" gesetzt: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):
.java
, kein.class
?Versuchen Sie, alles zu bereinigen und alles neu zu erstellen, und suchen Sie nach möglichen JAR-Konflikten .
quelle
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:
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).
quelle
Versuchen Sie, die von
jre
Ihnen verwendete zu ändern. Legen Sie diejre
in den Ordner vonJDK
stattdessen.quelle
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
Jetzt beschwert sich Eclipse nicht mehr über die Meldung "Haltepunkt-Abwesenheitsnummer kann nicht eingefügt werden" und die Debugging-Haltepunkte funktionieren tatsächlich !!!
quelle
Wenn nichts anderes funktioniert, öffnen Sie die Debug-Perspektive, löschen Sie alle vorhandenen Haltepunkte und setzen Sie sie erneut zurück.
quelle
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):
quelle
Meine Situation war ähnlich:
spyTask = spy(new Task())
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
quelle
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 :)
quelle
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.
quelle
Ich habe noch einen weiteren Grund für diese Nachricht gefunden. Ich habe Scala programmiert. Die Lösung war:
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.
quelle
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.)
quelle
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!
quelle
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:
quelle
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.
quelle
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.
Ich bin mir nicht sicher, ob es der gleiche Fall war.
quelle
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:
Add line number attributes...
org.eclipse.jdt.core.prefs
wie in einer anderen Antwort erwähnt: https://stackoverflow.com/a/31588700/1599699Ich 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.
quelle
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.
quelle
Überprüfen / tun Sie Folgendes:
1) Unter "Fenster -> Einstellungen -> Java -> Compiler -> Generierung von Klassendateien" müssen alle Optionen auf True stehen:
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.
quelle
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.
quelle
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.
quelle
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.
quelle
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.
quelle