JOSM kaputt -> unbrauchbar

Symptom:
Der Computer friert beim Arbeiten mit JOSM sehr häufig ein. Es hilft dann nur noch ein hartes Ausschalten, mit allen daraus folgenden Problemen. Dieser Fehler tritt dabei zu mehr als 99% (evtl. sogar 100%) nur ein, wenn ich einem Objekt (Knoten, Weg) ein Attribut (Schlüssel-Wert-Paar) hinzufügen möchte, und zwar nach dem Drücken des “Hinzufügen”-Knopfes. Ich kann mich nicht erinnern, daß es auch beim Ändern von Attributen aufgetreten ist. Beim Löschen ist es nicht aufgetreten, aber diese Aussage ist nicht besonders stark, da ich fast nichts lösche.

Häufigkeit:
Mittlerweile (heute) bei deutlich mehr als jeder fünften(!!!) Änderung, was ein Arbeiten unmöglich macht. Anmerkung: ich habe heute nach dem ersten Auftreten JOSM mit der Version 4487 installiert.

Beginn:
Schwer zu sagen, da das Problem nach Bauchgefühl schleichend anfing und immer häufiger auftrat. Es könnte so vor etwa drei Monaten angefangen haben. Ich installiere regelmäßig neue JOSM-Versionen (aus dem OpenSuse-Archiv) – schon wegen des Problems und mit der Hoffnung, daß es mit einer neuen JOSM-Version wieder verschwindet.

Ursache JOSM:
Da sich in der fraglichen Zeit die Umgebung (Hardware, Betriebssystem, Java-Laufzeitumgebung) nicht geändert hat, sollte das Problem in JOSM liegen. Ich habe mit keiner anderen Anwendung irgendwelche Probleme. Zudem arbeite ich sehr häufig mit der Eclipse-Entwicklungsumgebung an einer Java-Anwendung, welche ich auch nutze. Beide verwenden dieselbe Java-Laufzeitumgebung wie JOSM und zeigen keinerlei Probleme. Allerdings verwenden sie nicht Swing…

Schaden:
Das ständige harte Ausschalten ist sicher nicht gut. Ich hatte heute trotz ständem Sichern und sehr häufigem Hochladen immer wieder Schiefstände. Dies führte wiederholt zu doppelten Knoten und Wegen. Ich habe versucht, den Schaden zu bereinigen, bin mir aber nicht sicher, ob nun alles stimmt.

Angaben zu meiner Umgebung:
xxx@localhost:~> cat /proc/version
Linux version 2.6.34.10-0.2-desktop (geeko@buildhost) (gcc version 4.5.0 20100604 [gcc-4_5-branch revision 160292] (SUSE Linux) ) #1 SMP PREEMPT 2011-07-20 18:48:56 +0200
xxx@localhost:~> java -version
java version “1.6.0_22”
OpenJDK Runtime Environment (IcedTea6 1.10.2) (suse-4.2.1-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)

Kennt jemand dieses Problem auch?

Ich werde sicherheitshalber noch (versuchen) einen Bug zu erfassen.

Nö, dass Problem ist mir unbekannt.
Ich installiere häufig neue JOSM-Versionen (1 bis 3x die Woche), aber stets selbst kompiliert.

Wäre interessant, welche plugins Du verwendest, also den ersten Teil des Statusberichts.

Mal ein paar (evtl. alle) plugins entfernen und neu testen.

Ich habe genau ein Plugin installiert: licencechange: Version 26606 (lokal 26606)

Da ich das Plugin (nach einigen anfänglichen Überprüfungen) seit längerem praktisch nicht mehr nutze, erwarte ich die Ursache nicht hier, aber ich werde es mal testen…

einfach mal .josm auf deiner home-directory umbenennen oder gleich löschen und dann josm neu aufrufen.

rm -r ~/.josm

alle plugins und eigene einstellungen wären da weg aber wenn es der wahrheitsfindung dient … :wink:

gruss
walter

Ein Punkt ist mir doch noch aufgefallen: die Java-Umgebung:

OpenSuse hat einen besonderen Mechanismus zum Verwalten mehrer Java-Umgebungen. Standardmäßig wird IcedTea (OpenJDK) verwendet. Beim ersten Installieren von JOSM wurde mir aber eine Abhängigkeit zu Sun-Java angezeigt, welches zusammen mit JOSM installliert wurde. Die Pfade sind so, daß IcedTea von allen Anwendungen gefunden wird. JOSM scheint aber wirklich Sun-Java zu benutzen. Ich habe nur noch nicht herausgefunden, wie es diese Umgebung findet… Könnte also doch sein, daß das Problem mit der Sun-Java-Umgebung verbunden ist… Ich weiß auch nicht, warum das JOSM-Paket auf der OpenSuse-Update-Site als einziges (der von mir genutzten Paktete) die Sun-Java-Umgebung haben will, alle anderen aber OpenJDK.

nö, rennt genauso gut mit openjdk.
hast du schon .josm platt gemacht? das ist zu 95% die Lösung.

ich hatte vor etwa 1 1/2 jahren mit einigen josm-versionen das gleiche problem. auch unter linux, aber damals noch 32bit…
bei mir trat sehr oft dieser fehler auf, wenn ich einen oder mehrere gps-tracks geöffnet hatte. als dann mal eine version kam, die dieses problem nicht mehr hatte, habe ich sehr lange nicht mehr upgedatet. aber seither hatte ich dann dieses problem nicht mehr. zur zeit verwende ich version 4512 - ohne probleme (habe letzthin aber keine gps-tracks damit geöffnet)…