# Manche Breakpoints werden in Eclipse nicht beachtet



## boesi (30. Jul 2009)

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 (30. Jul 2009)

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 (30. Jul 2009)

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 (30. Jul 2009)

deathbyaclown hat gesagt.:


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


deathbyaclown hat gesagt.:


> 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 (30. Jul 2009)

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 (30. Jul 2009)

schalentier hat gesagt.:


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



schalentier hat gesagt.:


> 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 (30. Jul 2009)

Vayu hat gesagt.:


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



Vayu hat gesagt.:


> 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 (30. Jul 2009)

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


----------



## Wildcard (30. Jul 2009)

boesi hat gesagt.:


> 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 (30. Jul 2009)

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 (31. Jul 2009)

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


----------



## Gonzo17 (31. Jul 2009)

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 (31. Jul 2009)

Gonzo17 hat gesagt.:


> 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 (31. Jul 2009)

Vayu hat gesagt.:


> 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 (3. Aug 2009)

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 (3. Aug 2009)

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


----------



## maki (3. Aug 2009)

> 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 (3. Aug 2009)

Vayu hat gesagt.:


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


maki hat gesagt.:


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


maki hat gesagt.:


> Leg dir doch einen neuen Workspace an.


hab ich das nicht? ???:L


----------



## maki (3. Aug 2009)

> hab ich das nicht?


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


----------



## boesi (4. Aug 2009)

Vayu hat gesagt.:


> 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 (4. Aug 2009)

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 (4. Aug 2009)

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


----------



## boesi (5. Aug 2009)

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 (5. Aug 2009)

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 (5. Aug 2009)

boesi hat gesagt.:


> 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 (5. Aug 2009)

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 (5. Aug 2009)

musiKk hat gesagt.:


> 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 (14. Aug 2009)

boesi hat gesagt.:


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


----------

