[Elipse Mars] JUnit View lastet CPU voll aus

T

Tersus

Gast
Grüßt euch,

ich habe, wie immer, massive Probleme mit Eclipse. Wenn ich in der Java Perspective IDLE, dann ist meine CPU ruhig und bleibt so bei 30°C. Sobald ich in die Debug Perspective wechsle und diese sich bereits aufgebaut hat, ballert meine CPU hoch und ist selbst im IDLE bei 65°C Tendenz steigend.

Dann zu dem Punkt JUnit. Wenn ich in der Java Perspective meine TestKlasse mittels JUnit starte, passiert rein gar nichts, außer dass die CPU hoch ballert. Erst wenn ich in die Debug Perspective wechsle, terminiert der Test Run!

Das ist doch zum Haare ausreißen. :pcangry:
 
Zuletzt bearbeitet von einem Moderator: (Titeländerung)
AW: [Elipse Mars] hohe Auslastung in der Debug Persprective trotz IDLE

Wo ist jetzt deine Frage?

Ok, ich versuch mal darauf einzugehen..

Ist dein JUnit View auch in der Debug persepective gepinnt oder nicht?
Das würde schonmal ein Punkt erklären.

Wenn ich in der Java Perspective IDLE

Sorry, aber kp.


Sobald ich in die Debug Perspective wechsle und diese sich bereits aufgebaut hat, ballert meine CPU hoch und ist selbst im IDLE bei 65°C Tendenz steigend.

Naja, wenns IDLE ist wie soll dann ist die CPU-Temp hoch sein? Das ist bei dir nicht der Fall, also KEIN IDLE.

passiert rein gar nichts, außer dass die CPU hoch ballert.

Beide Aussagen widersprechen sich.
Wenn du in deinen Test eine Endlosschleife eingebaut hast, dann kannst du es nicht auf Eclipse schieben.


Sorry, aber deiner Beschreibung nach sitzt das Problem vor dem Bildschirm.
 
Zuletzt bearbeitet:
AW: [Elipse Mars] hohe Auslastung in der Debug Persprective trotz IDLE

Danke dir erst einmal für deinen Beitrag. Ich versuche mal Ordnung in das Chaos zu bringen.

Mit IDLE meinte ich, dass ich selbst nicht am Rechner arbeite, sondern nur auf den Bildschirm schaue, ohne zumindest aktiv etwas auszuführen.

Du hast aber recht, es liegt anscheinend an der gepinnten JUnit View. Diese habe ich nun sowohl in der Java Perspective als auch in der Debug Perspective. Und immer wenn die gepinnte JUnit View der ausgewählte Reiter ist, dann passiert anscheinend ohne mein Zutun etwas im Hintergrund. Erklären kann ich mir das aber nicht. Nur weil die JUnit View aktiv ist, kann doch nicht plötzlich der Rechner heiß laufen?

Nun zum Problem JUnit TestRun. Meine TestKlasse löst definitiv keine Endlosschleife aus, die das fest hängen von Eclipse erklären würde, sondern prüft ganz primitiv mittels assertEquals(...) zwei banale Werte.

Wenn ich also in der Java Perspective ein run mit JUnit durchführe, dann friert Eclipse manchmal vollständig fest und wenn es nicht vollständig fest friert, dann terminiert zumindest der TestRun einfach nicht, bzw. erst, wenn ich in die Debug Perspective wechsle! Ist doch sehr seltsam.

Meine Fragen:
Was arbeitet die CPU im Hintergrund, wenn die gepinnte JUnit View angezeigt wird, man aber gar nichts am Rechner tätigt?
Wieso spinnt JUnit bei mir in der Java Perspective?

Grüße
 
AW: [Elipse Mars] hohe Auslastung in der Debug Persprective trotz IDLE

Tersus schrieb:
Mit IDLE meinte ich, dass ich selbst nicht am Rechner arbeite, sondern nur auf den Bildschirm schaue, ohne zumindest aktiv etwas auszuführen.

Das du nichts tust ist an diese Stelle irrelevant, interessant wäre es zu erfahren was dein Rechner tut -> Debuggen.

Tersus schrieb:
Und immer wenn die gepinnte JUnit View der ausgewählte Reiter ist, dann passiert anscheinend ohne mein Zutun etwas im Hintergrund. Erklären kann ich mir das aber nicht. Nur weil die JUnit View aktiv ist, kann doch nicht plötzlich der Rechner heiß laufen?

Das sollte tatsächlich nicht sein.
Mein Vorschlag: lade Eclipse neu herunter (keine Installer Version!) erstelle ein neues Workspace und öffne die JUnit View.
Sollte das Problem weiterhin bestehen so wird es wohl ein Bug in Eclipse sein.
Ich würde empfehlen in diesem Fall ein älteres Release zu verwenden oder Intellij IDEA auszuprobieren.

Tersus schrieb:
Nun zum Problem JUnit TestRun. Meine TestKlasse löst definitiv keine Endlosschleife aus, die das fest hängen von Eclipse erklären würde, sondern prüft ganz primitiv mittels assertEquals(...) zwei banale Werte.

Das kann ich dir nicht sagen solange ich dein Code nicht gesehen habe ;)

Tersus schrieb:
Wenn ich also in der Java Perspective ein run mit JUnit durchführe, dann friert Eclipse manchmal vollständig fest und wenn es nicht vollständig fest friert, dann terminiert zumindest der TestRun einfach nicht, bzw. erst, wenn ich in die Debug Perspective wechsle! Ist doch sehr seltsam.

Das kann man entweder mit einer Endlosschleife erklären oder mit einer kaputten Eclipse Version/Installation, ersteres ist aber um vielfaches wahrscheinlicher.

Du kannst in dem du einfach irgendwo in deinem Testcode ein Rechtsklick machst im Debug Untermenu "debug JUnit test" auswählen dein Unit Test debuggen (Setzte ein Breakpoint ganz am Anfang deines Testcodes, falls vorhanden in der SetUp Methode und schaue erst einmal ob du so weit kommst).

Ich hoffe das bringt dich ein Schritt weiter.
 
AW: [Elipse Mars] hohe Auslastung in der Debug Persprective trotz IDLE

Ich habe es mittels Ressourcen Manager kontrolliert. Die JUnit View, sobald als aktiver/sichtbarer Reiter, lastet meine CPU komplett aus, auch wenn man den TestRunner gar nicht laufen hat! Das ist doch definitiv ein Bug.

pmkrefeld schrieb:
Das sollte tatsächlich nicht sein.
Mein Vorschlag: lade Eclipse neu herunter (keine Installer Version!) erstelle ein neues Workspace und öffne die JUnit View.
Sollte das Problem weiterhin bestehen so wird es wohl ein Bug in Eclipse sein.
Ich würde empfehlen in diesem Fall ein älteres Release zu verwenden oder Intellij IDEA auszuprobieren.
Das werde ich demnächst tun, ja.

pmkrefeld schrieb:
Das kann man entweder mit einer Endlosschleife erklären oder mit einer kaputten Eclipse Version/Installation, ersteres ist aber um vielfaches wahrscheinlicher.
Eine Endlosschleife ist bei assertEquals(1, 1) unmöglich. ;) Zumal der Test positiv meldet, wenn ich kurz aus der JUnit View in den Package Explorer wechsle und dann wieder zurück zur JUnit View ... . Das ist derzeit der einzige Weg, dass der TestRunner terminiert.
 
Zurück
Oben