Hallo,
Ich stehe vor einem ziemlichen Rätsel und bin echt mit dem Latein oder allen anderen verfügbaren Sprachen am Ende:
Einleitung
Ich entwickle eine (für mich) komplexe Mutliagenten-Simulation. Diese umfasst einen Agententypen, drei verschiedene Verhaltensweisen. Dabei entnimmt das Programm die grundlegende Programmparameter aus einer Parameterdatei, sowie die Parameter für die Simulation aus einem Geodatensatz.
Das Programm stützt sich dabei auf
ein Multiagenten-Framework (MASON),
sowie dessen "Addon" (GeoMason),
eine Lösung von zum einlesen von Geodaten (vividsolutions.jts)
und einer Entwicklung aus eingenem Hause zur Vektorrechnung
Problem
Mit der eigentlichen Simulation war ich fast fertig (dachte ich), sodass ich nur noch die grafische Ausgabe hätte gestalten müssen. Seit der letzten Änderung (ich hatte eine Methode bearbeitet und eine neu eingefügt) stoße ich aber auf ein faszinierendes Problem:
- Das ganze Programm bleibt stecken (steht), läuft aber noch <- es wurde also nicht beendet, sondern tut einfach nichts mehr
Warum faszinierend, fragt Ihr Euch sicher?
Ich habe natürlich auch zunächst an einen Programmierfehler gedacht und nach einer Endlosschleife oder einer endlosen Rekursion gesucht.
Ja, ich weiß, normalerweise müsste eine endlose Rekursion irgendwann zum StackOverflow führen. Es existiert (witzigerweise in einer der beiden Methoden) ein Workaround, der rekursiv umgesetzt wurde (bitte nicht hauen...). Dieser arbeitet jedoch mit einem Counter, der die Rekursion in der 10. Wiederholung abbricht und einen Zufallsschritt ausführt.
Da ich den Fehler nicht identifizieren konnte, habe ich die beiden Methoden auskommentiert - also sie werden nicht mehr aufgerufen. Trotzdem blieb das Programm stecken. Als ich eine der beiden wieder aufgenommen hatte, lief das Programm mehrere "Steps" (Aktionen in der laufenden Simulation) durch und bliebt stecken. Daraufhin nahm ich die Methode raus und die andere rein... das Programm lief an und blieb wieder nach wenigen "Steps" hängen.
Daraufhin hatte ich beide problemlos in der Verwendung und mehrere Tests verliefen bis zur Abbruchbedingung (50.000 Steps) vollständig durch (wir sprechen hier von einer Rechenzeit von zwei Stunden für einen vollständigen Simulationsdurchlauf). Als ich daraufhin eine System.out.println-Zeile eingefügt hatte, blieb das Programm sofort nach start der Simulation hängen.
Ich entfernte natürlich diese Zeile wieder und trotzdem blieb das Programm dauerhaft direkt beim Start hängen. Es wurde keine andere Änderung vorgenommen.
Problemzusammenfassung
-> Das Programm bleibt hängen, wird aber nicht beendet;
-> Es werde keine Exceptions geloggt (alle mit catch-Block tragen ihren StackTrace in eine Datei und eine Warnmeldung in die Konsole/LogDatei ein)
-> Stelle scheinbar zufällig, aber ohne Änderung am Quellcode immer an der selben Stelle;
-> Änderungen am Quellcode führen zu Änderungen der Abbruchstelle, die Rücknahme der Änderung stellt aber scheinbar den vorigen Stand nicht wieder her.
-> Es sind keine Endlosschleifen / Rekursionen ohne Ende auffindbar.
-> Problem tritt sowohl in Eclipse auf, als auch in der compilierten .jar-Datei
-> Problem tritt nur im Simulationsteil auf. Alle vorheringen Schritten werden korrekt ausgeführt (Parameterdatei einlesen, Geodatensatz einlesen, Objekte erzeugen, Simulation vorbereiten (Agenten erzeugen, Parameter setzen)
-> Es scheint nicht an "kritischen Stellen" stehen zu bleiben. Teilweise hängt es einfach zwischen zwei println-Zeilen, zwischen denen keine andere Anweisung steht.
Lösungsversuche (offensichtlich ohne Erfolg)
-> Deaktivierung ALLER Zufallsvariablen und ersetzen durch fixe Werte
-> Start der .jar-Datei auf einem anderen Rechner (hier wieder Stuck-Error an der selben Stelle)
-> Zuweisung von mehr Speicher (Verzweiflungsversuch: ich hatte der JVM zunächst 4GB zugesichert, dann bis zur Freigabe von 16GB hochgegangen)
-> Das Programm mehrere Stunden in der Ruhe lassen (um zu schauen, ob es vielleicht nur unglaublich langsam ist)
Fragen
So langsam verzweifle ich wirklich ... kann es sein, dass meine JVM selbst einen Sockenschuss weg hat? Aber wieso stoße ich auf anderen Systemen auf den selben Fehler? (dort müsste die .jar dann doch korrekt laufen)
Hat Jemand so ein Problem schon erlebt und/oder eine Lösung dafür?
Ich glaube eigentlich immer noch an einen total bescheuerten Programmierfehler von mir oder einem der anderen Jungs, aber ich finde den auf Gedeih und Verderb nicht oO
Ich stehe vor einem ziemlichen Rätsel und bin echt mit dem Latein oder allen anderen verfügbaren Sprachen am Ende:
Einleitung
Ich entwickle eine (für mich) komplexe Mutliagenten-Simulation. Diese umfasst einen Agententypen, drei verschiedene Verhaltensweisen. Dabei entnimmt das Programm die grundlegende Programmparameter aus einer Parameterdatei, sowie die Parameter für die Simulation aus einem Geodatensatz.
Das Programm stützt sich dabei auf
ein Multiagenten-Framework (MASON),
sowie dessen "Addon" (GeoMason),
eine Lösung von zum einlesen von Geodaten (vividsolutions.jts)
und einer Entwicklung aus eingenem Hause zur Vektorrechnung
Problem
Mit der eigentlichen Simulation war ich fast fertig (dachte ich), sodass ich nur noch die grafische Ausgabe hätte gestalten müssen. Seit der letzten Änderung (ich hatte eine Methode bearbeitet und eine neu eingefügt) stoße ich aber auf ein faszinierendes Problem:
- Das ganze Programm bleibt stecken (steht), läuft aber noch <- es wurde also nicht beendet, sondern tut einfach nichts mehr
Warum faszinierend, fragt Ihr Euch sicher?
Ich habe natürlich auch zunächst an einen Programmierfehler gedacht und nach einer Endlosschleife oder einer endlosen Rekursion gesucht.
Ja, ich weiß, normalerweise müsste eine endlose Rekursion irgendwann zum StackOverflow führen. Es existiert (witzigerweise in einer der beiden Methoden) ein Workaround, der rekursiv umgesetzt wurde (bitte nicht hauen...). Dieser arbeitet jedoch mit einem Counter, der die Rekursion in der 10. Wiederholung abbricht und einen Zufallsschritt ausführt.
Da ich den Fehler nicht identifizieren konnte, habe ich die beiden Methoden auskommentiert - also sie werden nicht mehr aufgerufen. Trotzdem blieb das Programm stecken. Als ich eine der beiden wieder aufgenommen hatte, lief das Programm mehrere "Steps" (Aktionen in der laufenden Simulation) durch und bliebt stecken. Daraufhin nahm ich die Methode raus und die andere rein... das Programm lief an und blieb wieder nach wenigen "Steps" hängen.
Daraufhin hatte ich beide problemlos in der Verwendung und mehrere Tests verliefen bis zur Abbruchbedingung (50.000 Steps) vollständig durch (wir sprechen hier von einer Rechenzeit von zwei Stunden für einen vollständigen Simulationsdurchlauf). Als ich daraufhin eine System.out.println-Zeile eingefügt hatte, blieb das Programm sofort nach start der Simulation hängen.
Ich entfernte natürlich diese Zeile wieder und trotzdem blieb das Programm dauerhaft direkt beim Start hängen. Es wurde keine andere Änderung vorgenommen.
Problemzusammenfassung
-> Das Programm bleibt hängen, wird aber nicht beendet;
-> Es werde keine Exceptions geloggt (alle mit catch-Block tragen ihren StackTrace in eine Datei und eine Warnmeldung in die Konsole/LogDatei ein)
-> Stelle scheinbar zufällig, aber ohne Änderung am Quellcode immer an der selben Stelle;
-> Änderungen am Quellcode führen zu Änderungen der Abbruchstelle, die Rücknahme der Änderung stellt aber scheinbar den vorigen Stand nicht wieder her.
-> Es sind keine Endlosschleifen / Rekursionen ohne Ende auffindbar.
-> Problem tritt sowohl in Eclipse auf, als auch in der compilierten .jar-Datei
-> Problem tritt nur im Simulationsteil auf. Alle vorheringen Schritten werden korrekt ausgeführt (Parameterdatei einlesen, Geodatensatz einlesen, Objekte erzeugen, Simulation vorbereiten (Agenten erzeugen, Parameter setzen)
-> Es scheint nicht an "kritischen Stellen" stehen zu bleiben. Teilweise hängt es einfach zwischen zwei println-Zeilen, zwischen denen keine andere Anweisung steht.
Lösungsversuche (offensichtlich ohne Erfolg)
-> Deaktivierung ALLER Zufallsvariablen und ersetzen durch fixe Werte
-> Start der .jar-Datei auf einem anderen Rechner (hier wieder Stuck-Error an der selben Stelle)
-> Zuweisung von mehr Speicher (Verzweiflungsversuch: ich hatte der JVM zunächst 4GB zugesichert, dann bis zur Freigabe von 16GB hochgegangen)
-> Das Programm mehrere Stunden in der Ruhe lassen (um zu schauen, ob es vielleicht nur unglaublich langsam ist)
Fragen
So langsam verzweifle ich wirklich ... kann es sein, dass meine JVM selbst einen Sockenschuss weg hat? Aber wieso stoße ich auf anderen Systemen auf den selben Fehler? (dort müsste die .jar dann doch korrekt laufen)
Hat Jemand so ein Problem schon erlebt und/oder eine Lösung dafür?
Ich glaube eigentlich immer noch an einen total bescheuerten Programmierfehler von mir oder einem der anderen Jungs, aber ich finde den auf Gedeih und Verderb nicht oO
