josm landet in Endlosschleife?

Moin,
nachdem sich josm bei mir neulich merkwürdig benommen hat, habe ich alle Einstellungsdateien gelöscht und josm neu installiert. Seitdem kommt er beim Start noch bis zu der Ausgabe “Bildeinstellungen werden geladen” und anschliessend geht das Ding in eine Endlosschleife, bei der ein Core voll ausgelastet wird, die Animation mit dem “Wanderbalken” auf dem Infofenster läuft weiter und ansonsten passiert nix mehr bis man josm abschiesst. Hat schon mal jemand so einen Effekt gesehen und eine Idee, wo das möglicherweise klemmt?
Fragende Grüße,
Wolfgang

Ich habe auch keine Idee, aber wenn du noch Informationen über

  • deine JOSM-Version
  • dein Betriebssystem
  • deine Java-Version und -fabrikat

… mitlieferst, könnte das für die Leute, die Ideen haben, wertvoll sein.

–ks

Ich vermute mal Windows - war bei mir auch einmal.

Installiere neue Versionen immer über Windows-Installer-Version.

Zuerst aufgefallen ist es mir mit JOSM 14460 (heruntergeladen), zuletzt probiert habe ich es mit 14589 (direkt aus dem Source gebaut). Wenn ich die Testsuite aus dem Sourcepaket laufen lasse, kommt er bis zu folgender Ausgabe:


[junit] Running org.openstreetmap.josm.data.imagery.WMTSTileSourceTest

und versackt dann in einer Endlosschleife, die alle Cores voll auslastet.

Betriebssystem ist FreeBSD, sowohl Version 11.2 als auch 12.0, Java ist OpenJDK 8.192.26_3

Probier mal einen Stacktrace zu erzeugen. Ist bekannt wie das geht? Falls nicht: https://access.redhat.com/solutions/18178

Das sollte auch unter FreeBSD ein KILL -3 JAVA_PID sein. jstack sollte eigentlich auch funktionieren und direkt einen Callstack zurückliefern, den man irgendwohin speichern kann.

Ist es. Ich habe das jetzt gemacht, der einzige für mich auffällige thread sieht so us:


"main-init-1" #24 prio=5 os_prio=15 tid=0x000000089c5e1000 nid=0x188c3 runnable [0x00007fffde4e3000]
   java.lang.Thread.State: RUNNABLE
        at org.openstreetmap.josm.actions.JoinAreasAction$WayTraverser.getAngle(JoinAreasAction.java:333)
        at org.openstreetmap.josm.actions.JoinAreasAction$WayTraverser.leftComingWay(JoinAreasAction.java:421)
        at org.openstreetmap.josm.actions.JoinAreasAction.findBoundaryPolygons(JoinAreasAction.java:1175)
        at org.openstreetmap.josm.actions.JoinAreasAction.joinAreas(JoinAreasAction.java:664)
        at org.openstreetmap.josm.tools.RightAndLefthandTraffic.computeOptimizedBoundaries(RightAndLefthandTraffic.java:121)
        at org.openstreetmap.josm.tools.RightAndLefthandTraffic.initialize(RightAndLefthandTraffic.java:72)
        - locked <0x0000000814356e38> (a java.lang.Class for org.openstreetmap.josm.tools.RightAndLefthandTraffic)
        at org.openstreetmap.josm.gui.MainInitialization$$Lambda$144/1233505227.run(Unknown Source)
        at org.openstreetmap.josm.spi.lifecycle.InitializationTask.call(InitializationTask.java:33)
        at org.openstreetmap.josm.spi.lifecycle.InitializationTask.call(InitializationTask.java:11)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

Diesen Stack trace habe ich nach 150 Sekunden Laufzeit erzeugt, die letzte ausgegebene Zeile war da seit mehr als 2 Minuten das “Bildeinstellungen werden geladen”.

Der Test hängt wohl in JoinAreasAction.java, Zeile 333, und dort in einer Methode getAngle. Schauen wir da mal rein.


        private static double getAngle(Node n1, Node n2, Node n3) {
            EastNorth en1 = n1.getEastNorth();
            EastNorth en2 = n2.getEastNorth();
            EastNorth en3 = n3.getEastNorth();
            double angle = Math.atan2(en3.getY() - en1.getY(), en3.getX() - en1.getX()) -
                    Math.atan2(en2.getY() - en1.getY(), en2.getX() - en1.getX());
            while (angle >= 2*Math.PI) {
                angle -= 2*Math.PI;
            }
            while (angle < 0) {
                angle += 2*Math.PI;              <<< Zeile 333
            }
            return angle;
        }

getAngle versucht wohl so oft 2 pi zu angle zu addieren, bis der Winkel in Bereich [0; 2*Math.PI[ liegt. Es könnte sein, dass bei der atan2 Berechnung aus irgendwelchen Gründen merkwürdige Werte herauskommen, und das kann dann dauern. Dazu müsste man mal schauen, ob in n1, n2 und n3 sinnvolle Werte drin stehen, und wenn ja, was dann bei OpenJDK für die atan2 Berechnung herauskommt.

Ich habe mal folgende Debugausgabe vor die Korrekturschleifen gesetzt:


Logging.trace("getAngle ({0}/{1}) ({2}/{3}) ({4}/{5}) : {6}", en1.getX(), en1.getY(), en2.getX(), en2.getY(), en3.getX(), en3.getY(), angle);

Die meisten Aufrufe liefern für angle Werte übersichtlicher Größe; die eine Ausnahme ist aber der allerletze Aufruf, der folgendes liefert:


2019-01-19 13:37:51.208 AM FEINSTEN: getAngle (-19.389.523,153/-1.682.864,705) (-19.273.231,02/-1.682.549,013) (-19.677.752,692/-1.683.649,344) : -1.723.428.870.181.259.000.000.000.000.000.000.000.000.000.000.000.000.000.000

Zu dem Wert kann man zugegebenermassen ziemlich oft 2*Pi addieren bis der positiv wird. Ob die Werte die da reingehen in irgendeiner Weise sinnvoll sind, kann ich nicht beurteilen; bei den anderen Aufrufen von getAngle sehen die aber ähnlich aus.

Ich denke, es wäre wohl am besten, dafür so ein Ticket aufzumachen: https://josm.openstreetmap.de/newticket

Evtl. ist eine kaputte left-right-hand-traffic.osm im cache Verzeichnis. Kannst Du mal umbennen und schauen, ob das hilft. Falls ja, dann bitte nicht wegwerfen, sondern einen Link posten.

Unendlich oft. Das Addieren von 2Pi ändert garnichts wenn 2Pi hinter den 15 Dezimalstellen Genauigkeit liegt.

atan2 sollte nur Werte zwischen -pi und pi oder NaN liefern.

Schon seltsam. Sieht ja fast nach einem Hardware bug aus,wie früher beim Pentium :wink:
Zur Erklärung: JOSM saugt die Datei left-right-hand-traffic.osm runter und verwendet die, um Gebiete mit Links-Verkehr zu erkennen.
Ursprünglich habe sich da wohl Gebiete überlappt. Die Datei wurde auf der Server Seite so verbessert, das man gar nicht mehr an diese problematische Stelle kommen sollte.
Anscheinend klemmt aber was bei der Erkennung, dass da immer die alte Version aus dem cache Verzeichnis verwendet wird.
Ich hatte damit vor Monaten auch mal Probleme.

Korrektur: Die Datei wird NICHT von Server runtergesogen, sie kommt aus dem JOSM jar (boundaries.osm). Aus dieser Datei wird die left-right-hand-traffic.osm berechnet, und dazu wird die JoinAreasAction verwendet, bei der es zu Problemen kommt. Wenn die Date vorhanden ist, wird nicht neu berechnet und es sollte nicht zu diesem Fehler kommen.

@lyx: Bei Dir wird es also diese Datei nicht geben, der Fehler dürfte in der Hardware oder in der JRE liegen. Vielleicht versuchst Du mal, die double Werte als Long auszugeben (Double.doubleToLongBits()) , dann müsste man eigentlich in der Lage sein, das Problem mit einem kleinen Testprogramm zu reproduzieren.
Man kann zwar in den beiden Schleifen das while durch ein if ersetzen, aber das vermeidet nur den Loop, ein richtiges Ergebnis kommt dann auch nicht raus.

eidt2: NICHT runtergesogen

Zur Info: Ich habe ein JOSM Ticket eröffnet: 17224. Die ganze Berechnung ist eigentlich unnötig, der Patch vermeidet das zumindest beim JOSM Start.