Manche Breakpoints werden in Eclipse nicht beachtet

[boesi]

moin


ich nutze schon ne ganze Weile Eclipse und auch den Debug-Modus. Seit kurzem* ignoriert Eclipse nach dem Zufallsprinzip einzelne Breakpoints. Andere Breakpoints funktionieren aber immer. Oder eine Methode wird von einem EventHandler 2x aufgerufen - beim 1. mal wird der Breakpoint ignoriert, beim 2. mal hält das Programm. Bis hierhin ist das Verhalten merkwürdig aber konsistent.

Jetzt hab ich mal ein clean ausgeführt und prompt werden gar keine Breakpoints mehr beachtet. Also hab ich alle Breakpoints gelöscht und neue gesetzt - jetzt ist wieder alles wie oben.

* einen genaueren Zeitpunkt kann ich leider nicht angeben

Wie bekomm ich nun Eclipse dazu, alle meine Breakpoints zu beachten?

Vielen Dank für Eure Hilfe
cu boesi

PS: Eclipse 3.5.0, JDK 1.6.14, Vista SP2

 

[bygones]

mhm ich setz eigentlich nur einen breakpoint an den start der prozess die mich interessieren - danach "hangel" ich mich ueber die "Step into" "step over" "Step return" moeglichkeiten.

ansonsten laesst er bei mir nur BP aus wenn auch der Code da nicht erreicht wird ?!

 

[schalentier]

Jo, bei uns mehrt sich dieses Problem auch gerade. Normalerweise tritt das auf, wenn Eclipse Probleme beim Uebersetzten hatte (siehe Problems-View) und trotzdem startet (mit einer veralteten .class-Datei). Dann ignoriert der Debugger die Breakpoints. Ein clean hilft dann meistens.

Allerdings hab ich inzwischen auf zwei Arbeitsrechner mit eignen Augen gesehen, dass im Eclipse weder der Debugger korrekt arbeitet, noch die Suche nach Klassen (Strg+Shift+T) oder Referenzensuche klappt. Auch ein clean, Restart, Projekt loeschen und erneut importieren hilft nicht... einizge Loesung: .metadata loeschen und Workspace neu einrichten :-(

 

[boesi]

mhm ich setz eigentlich nur einen breakpoint an den start der prozess die mich interessieren - danach "hangel" ich mich ueber die "Step into" "step over" "Step return" moeglichkeiten.

Naja ich will zB die Reaktion auf einen Klick auf einen Button debuggen - also setz ich in dem entsprechenden ActionLister einen Breakpoint - tja die Reaktion erfolgt aber das Programm hält nicht an.

ansonsten laesst er bei mir nur BP aus wenn auch der Code da nicht erreicht wird ?!

Ob eine Methode ausgeführt wird, läßt sich ja mit einfachen System.out-Befehlen überprüfen. Damit stelle ich dann zB fest, die Methode wird 2x aufgerufen. Sie soll aber nur 1x aufgerufen werden - ich setze also einen Breakpoint an den Beginn der Methode (konkret auf die Zeile mit der System.out-Anweisung). Aber das Programm stoppt erst beim 2. Durchlauf ...

Jetzt wird's noch merkwürdiger: Besagter doppelter Methodenaufruf führt zu ner Endlosschleife* - faktisch wird die Methode also unendlich mal aufgerufen. Ich hab jetzt auf jede Zeile dieser Methode einen Breakpoint gesetzt - nun stoppt das Programm plötzlich erst im x[>10]-ten Durchlauf in der letzten Zeile der Methode ...


* Die Endlosschleife ist nur ein Symptom und nicht das eigentliche Problem.

 

[Vayu]

welche eclipse version benutzt ihr?

ansonsten "reicht" es aus die ordner vom jdt.debug im .metadata zu löschen. dann muss man nicht den kompletten workspace neu einrichten.

 

[boesi]

Jo, bei uns mehrt sich dieses Problem auch gerade. Normalerweise tritt das auf, wenn Eclipse Probleme beim Uebersetzten hatte (siehe Problems-View) und trotzdem startet (mit einer veralteten .class-Datei). Dann ignoriert der Debugger die Breakpoints. Ein clean hilft dann meistens.

Sowohl ein Project->clean also auch Eclipse mit dem Parameter -clean starten, hat nix gebracht. In der Problems-View werden zwar diverse Warnings angezeigt aber keine Errors.

Allerdings hab ich inzwischen auf zwei Arbeitsrechner mit eignen Augen gesehen, dass im Eclipse weder der Debugger korrekt arbeitet, noch die Suche nach Klassen (Strg+Shift+T) oder Referenzensuche klappt. Auch ein clean, Restart, Projekt loeschen und erneut importieren hilft nicht... einizge Loesung: .metadata loeschen und Workspace neu einrichten :-(

Och nö nee das ist nich wahr ...
Der Dialog "Open Type" funktioniert bei mir weiterhin. Die Suche nach Referenz brauch ich eher selten, scheint aber auch nicht zu funktionieren. Vor allem behauptet die quasi sofort nix gefunden zu haben, sucht also scheinbar gar nicht.

 

[boesi]

welche eclipse version benutzt ihr?

3.5.0, davor 3.4.2 und ich glaube vor dem Update hatte ich das Problem nicht. Genau kann ich das aber nicht mehr nachvollziehen.

ansonsten "reicht" es aus die ordner vom jdt.debug im .metadata zu löschen. dann muss man nicht den kompletten workspace neu einrichten.

Ich hab aus dem .metadata mal alles gelöscht, was debug im Namen trägt. Hat aber nur den Effekt, dass meine Lauch-Configurations weg sind. [EDIT:] Die Breakpoints sind dabei nicht gelöscht wurden und funktionieren immer noch nicht richtig. Wo werden die Breakpoints denn gespeichert?

 

[Vayu]

ok evtl dann doch noch die jdt-ordner ... jdt is das java-plugin für eclipse

 

[Wildcard]

Wo werden die Breakpoints denn gespeichert?

Die Breakpoints sind AFAIK Marker bzwg. PersistentProperties auf den Dateien. Die Persistenz wird also vom Eclipse Resources PlugIn erledigt, also irgendwo in .metadata/org.eclipse.core.resources

 

[musiKk]

Also ich hab manchmal das Problem, dass sich Breakpoints nicht entfernen lassen. Besonders dann, wenn ich um markierte Zeilen herum etwas bearbeitet habe. Dann hilft "Remove All Breakpoints". Vielleicht bringt das bei diesem Problem ja auch was.
AEG (ausschalten, einschalten, geht) in irgendeiner Form funktioniert ja oft als erste Lösung.

 

[Vayu]

ich hatte mal bei diesem problem nur meine jdt ordner gelöscht und da waren die breakpoints auch mit weg

 

[Gonzo17]

Bei mir verschwinden seit einiger Zeit einfach mal ein paar Breakpoints, wenn ich Code ändere und die Datei abspeichere. Oder sie rutschen weiter runter an Stellen, an denen ich sie garnicht haben möchte (zB in andere Methoden). Benutze noch die Version 3.4.2 Ganymede. Aber größere Probleme hab ich damit nicht. Notfalls "Remove All Breakpoints" und danach neu setzen, das klappt immer.

 

[Vayu]

Bei mir verschwinden seit einiger Zeit einfach mal ein paar Breakpoints, wenn ich Code ändere und die Datei abspeichere. Oder sie rutschen weiter runter an Stellen, an denen ich sie garnicht haben möchte (zB in andere Methoden). Benutze noch die Version 3.4.2 Ganymede. Aber größere Probleme hab ich damit nicht. Notfalls "Remove All Breakpoints" und danach neu setzen, das klappt immer.

das "problem" gibts schon seit der 3.2 (vielleicht auch schon früher)

 

[boesi]

ok evtl dann doch noch die jdt-ordner ... jdt is das java-plugin für eclipse

Ich hab testweise aus dem .metadata-Verzeichniss verschiedene Sachen gelöscht (auch aus org.eclipse.core.resources und jdt.*). Aber alles, was nicht dazu führt, dass mein Workspace unbenutzbar wird, hilft auch bei den Breakpoints nicht ;(

Verdammt ich will nicht schon wieder mein Workspace neu einrichten müssen - allein das Zusammenklicken der verschiedenen Perspektiven dauert ne halbe Ewigkeit.

 

[boesi]

Gottverdammt (sorry ) nochmal die Woche fängt ja echt gut an. Hab jetzt doch das Verzeichniss .metadata komplett gelöscht und die Projekte wieder in Eclipse importiert.

Und was hat's gebracht? Nix - alles wie schon beschrieben.

Eins ist neu: Im Error Log tauchen jetzt Exceptions auf:
1. Problems occurred when invoking code from plug-in: "org.eclipse.debug.ui".
2. Error logged from Debug UI:

Jeweils mit einer NPE und immer schön im Wechsel.

Mannoh ich will meine Breakpoints wieder haben ;(

 

[Vayu]

hast du wenigstens deine metadaten gesichert? Dann würd ich Eclipse mal neu installieren und den workspace damit nochmal ausprobieren

 

[maki]

Hab jetzt doch das Verzeichniss .metadata komplett gelöscht und die Projekte wieder in Eclipse importiert.

Aua... sollte man nicht machen.

Leg dir doch einen neuen Workspace an.

 

[boesi]

hast du wenigstens deine metadaten gesichert? Dann würd ich Eclipse mal neu installieren und den workspace damit nochmal ausprobieren

Ja gesichert hab ich natürlich - und ich hab grad gesehen, dass im Installationsverzeichniss ja auch noch Konfigurationsdateien sind. Warum einfach, wenn's auch ...

Aua... sollte man nicht machen.

ja hab ich schon gemerkt, Eclipse vermißt ein paar der Dateien. Ich dachte halt, die werden wieder neu angelegt, wenn sie fehlen - was ja zum Teil auch passiert ist.

Leg dir doch einen neuen Workspace an.

hab ich das nicht? ???:L

 

[maki]

hab ich das nicht?

Offensichtlich nicht.
Ein "Switch Workspace" wäre das richtige

 

[boesi]

hast du wenigstens deine metadaten gesichert? Dann würd ich Eclipse mal neu installieren und den workspace damit nochmal ausprobieren

Soo hab jetzt das Eclipse-Installationsverzeichniss gesichert und Eclipse neuinstalliert (aka das Zip-Archiv entpackt). Dann mein Workspace-Verzeichniss gesichert und einen neuen Workspace angelegt. Die Projekte aus dem gesicherten Verzeichniss importiert (inklusive "Copy projects into workspace").

Und was hat's gebracht? Das Error Log ist wieder leer und die Breakpoints tun immer noch nicht so wie ich will ;(

 

[boesi]

Ich hab jetzt mal beobachtet, welche Breakpoints eigentlich ignoriert werden: Von der main-Funktion ausgehend werden alle Breakpoints beachtet, bis an einer Stelle ein Konstruktor von JPanel aufgerufen wird - der Brekpoint an dieser Stelle und alle danach liegenden Breakpoints werden ignoriert. Innerhalb der Klassen JPanel und JComponent kann ich aber sehr wohl funktionierende Breakpoints setzen.

Es wird noch ein bisschen spannender: Ich habe eine Klasse wie folgt

public class MyPanel extends JPanel {
	public MyPanel() {
		super();
		setOpaque(false);
	}
}

Wenn ich diese Klasse so instanziiere:

MyPanel panel = new MyPanel();

wird ein Breakpoint auf super(); beachtet, auf setOpaque(false); aber nicht.
Wenn ich dagegen einen namenslosen Konstruktur verwende:

MyPanel panel = new MyPanel() {{
	this.setOpaque(true);
}};

wird bereits der Breakpoint auf super(); ignoriert.

Wenn ich an den Anfang der main-Funktion einfach

MyPanel panel = new MyPanel();

setze, funktioniert auch der Breakpoint auf setOpaque(false);. Beim 2. Mal wird der Breakpoint dann aber ignoriert ... AAARRRGGGGGG

 

[Vayu]

alter finne das zeug ist echt hartnäckig, aber da steig ich echt bei aus ^^ so ein problem hatte ich noch nie

 

[boesi]

wenn ich meine Beschreibung richtig interpretiere, liegt das Problem also nicht an den Breakpoints selbst, sondern an dem Zustand in dem sich gerade Eclipse/Java/mein Programm/der jeweilige Thread/whatever gerade befindet.

Gibt es eine (einführende) Beschreibung wie der Debug-Modus in Eclipse funktioniert? Oder gibt es eine Möglichkeit den Debug-Modus selbst zu überwachen?

 

[boesi]

Aahhhh ich habs: Java SE 6 Update 15 Release Notes. - "Debug Issue"

Zusammenfassung: JVM mit -XX:+UseParallelGC starten und alles ist gut :lol:

Updating to 6u15 ...

 

[boesi]

Updating to 6u15 ...

Das Update auf 6u15 löst das Problem erstmal nicht - war nach den Release Notes aber ja auch nicht zu erwarten.

So bleibt entweder nur ein Downgrade auf 6u13 oder halt der alternative garbage collector.

 

[musiKk]

Schön, dass Du noch eine Lösung gefunden hast. Ich frage mich nur, warum das offenbar noch niemandem sonst passiert ist. Vista dürfte als Entwicklungsplatform jetzt nicht sooooo selten sein, dass sowas nie auftritt. Im Bug-Report ists auch nur Linux. Laut Release Note gibts das Problem mit dem falschen GC "on some platforms".
Naja, wie dem auch sei...

 

[boesi]

Schön, dass Du noch eine Lösung gefunden hast. Ich frage mich nur, warum das offenbar noch niemandem sonst passiert ist. Vista dürfte als Entwicklungsplatform jetzt nicht sooooo selten sein, dass sowas nie auftritt. Im Bug-Report ists auch nur Linux. Laut Release Note gibts das Problem mit dem falschen GC "on some platforms".
Naja, wie dem auch sei...

In den Kommentaren zum Bugreport steht aber auch was von XP SP3. Dann sind die "some platforms" wohl ausgerechnet Windows und Linux ...

Meine Frage nach Einführungen in die Arbeitsweise des Debuggers (also alles was über die Bedienung hinausgeht) bleibt aber bestehen ...

OT: Ein Klick auf "Frage offen" um das Thema als erledigt zu markieren, ist nicht wirklich intuitiv ...

 

[boesi]

Das Update auf 6u15 löst das Problem erstmal nicht - war nach den Release Notes aber ja auch nicht zu erwarten.

So bleibt entweder nur ein Downgrade auf 6u13 oder halt der alternative garbage collector.

Java SE 6 Update 16 Release Notes.