• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

OutOfMemoryError

Inder

Geowizard
Ein alter Freund ist wieder da:

java.lang.OutOfMemoryError: Used: 12244656, Need: 15376576

Beim Aktualisieren von 9 Caches hat er vier geschafft. Bei 5/9 war er da.

Windows-Exe
 
OP
Inder

Inder

Geowizard
Das Aktualisieren hat, wenn es mal funktioniert (derzeit braucht man mehrere Versuche und bevorzugt nur einzelne Caches, da ab zwei der Memory Error kommt), noch ein anderes Problem:

Ich erzeuge einen WP mit dem entsprechenden Cachenamen und lasse den aktualisieren. Name, Koordinaten etc. werden erkannt und angezeigt. Aber danach werden nicht mehr (wie früher) der Eintrag "Entfernung" und "Peilung" berechnet und gesetzt. Wenn man speichert und beendet, sind die Koordinaten nach dem erneuten Aufruf wieder verloren.
 
OP
Inder

Inder

Geowizard
Ein Rückgriff zur BE994 zeigt folgendes:

Aktualisieren klappt nur mit mehreren Anläufen. Häufig kommt auch der Memory Error dazwischen. Wenn es klappt, dann werden aber die Koordinaten korrekt gespeichert und Entfernung / Peilung angezeigt.

Es handelt sich dabei um Caches mit sehr vielen Logs. Eventuell ist das das Problem. (Zum Testen: GCD825 GCC43C GCG05M GCGWVP GCKJ1 GCWQJH GCD677 GCG39M)

Ist die 1002 wirklich eine 1002 oder hat sich da irgendwie die 979 (als die sie sich meldet) reingemogelt?
 

pfeffer

Geowizard
ich vermute, es liegt an dem /Xmx 12M, da hat mirabilos irgendetwas mit gemacht. Auf manchen Systemen scheint es Probleme zu verursachen, auf anderen Probleme zu lösen ...

@Developer: Das bedeutet, wir müssten für jede Platform eine eigen .jnf haben - was die ganze Sache aufwändiger zu warten machen würde hmpf.

Vielleicht könnte man auch alternativ /Xmx 12M weg lassen und immer eine Bat-Datei (shellskript) mit liefern, dass je nach Platform die Option setzt?

Gruß,
Pfeffer.
 

salzkammergut

Geomaster
@Pfeffer: Ich teile Deine Meinung. Ich kann Inder's Caches problemlos ohne Speicherprobleme spidern.

Die Idee mit der Skriptdatei finde ich gut.

Gruß
skg
 

mirabilos

Geocacher
Inder schrieb:
Ist die 1002 wirklich eine 1002 oder hat sich da irgendwie die 979 (als die sie sich meldet) reingemogelt?

Ja, hab im Buildlog nachgeguckt, der Ersetzungsbefehl
hat nicht geklappt gehabt. Tuts denn bei der r1016? Also
als was meldet die sich? (Ich hab keine Titelleisten, ich seh
das selber nicht.)

pfeffer schrieb:
ich vermute, es liegt an dem /Xmx 12M, da hat mirabilos irgendetwas mit gemacht.

Nein, habe ich nicht.

ERSTENS kam das nach der r1002
ZWEITENS betrifft das nur die CacheWolf.bat von der Jar-Version
DRITTENS habe ich nur den Konsens aus diesem Forum (daß man
das 12M weglassen soll) implementiert
 

Kalli

Geowizard
pfeffer schrieb:
Vielleicht könnte man auch alternativ /Xmx 12M weg lassen und immer eine Bat-Datei (shellskript) mit liefern, dass je nach Platform die Option setzt?
Ist es denn nicht so, dass der Parameter nur für die PDA-Version benötigt wird? Alle anderen Systeme sollten doch genügend Speicher haben. Evtl. ist der Zaurus da noch ein Sonderfall.

Gerade auf dem PDA haben wir aber keine Bat-Dateien. Ich wäre dafür, zwei .jnf-Dateien anzulegen, eine mit /Xmx 12M für die PDA-Versionen und eine ohne für den Rest.
 

mirabilos

Geocacher
Kann ich mich drum kümmern. Funktioniert denn zur Zeit bei allen
das String Pooling, oder muß man das auch irgendwo ausmachen?
(Wenn ich schon mal beim Mit-Jewel-Rumspielen bin…)
 

blackeye501

Geocacher
Muß es denn auf dem PDA unbedingt /Xmx 12M heißen ?
Oder funktioniert /Xmx12M auch ? Das ist nämlich der korrekte Aufruf in der Windows Version.
 
OP
Inder

Inder

Geowizard
Meinen unnötigen zweiten Thread zum gleichen Thema habe ich gelöscht. Hier noch kurz der Inhalt:

Gibt es inzwischen irgendein Bugfix der Windows-Version dafür?
Aktuell (ich habe jetzt die 1044 am Laufen) reicht das Aktualisieren eines einzigen Caches (GCGWVP), um den Fehler auszulösen.

Ergänzung:

Nachdem mich das Aktualisieren tierisch genervt hat, habe ich einen großen Teil der Caches gelöscht und lasse diese jetzt komplett neu spidern. Komischerweise taucht da der Fehler nicht auf, auch wenn viele Caches gleichzeitig geladen werden.
Nur die Hänger mit Stillstand tauchen beim Spidern ebenso auf, wie beim Aktualisieren. Subjektiv würde ich sagen, beim Spidern sind sie seltener. Das kann aber Zufall sein.
 

gbaer

Geonewbie
Hallo,
da ich schon lange ein Fan von CW bin, melde ich mich auch mal...
Habe die selben Probleme mit der 1044 bei GCCWVP mit java.lang.OutOfMemoryError auf Windows-Ebene. Wenn ich die Seite von GCCWVP mit allen Log`s öffne, dauert es ewig lange bevor diese angezeigt wird, egal zu welcher Uhrzeit.
Grüße und Danke an alle Macher :wink: von CW.
gbaer
 

pfeffer

Geowizard
das Problem liegt ja vermutlich am (fehlenden) /Xmx12M mirabilos hat zwar gesagt, er wolle sich darum kümmern, aber das kann er in absehbarer Zeit leider doch nicht. Er ist leider auch nicht mehr erreichbar.
[DEV]:
Vielleicht kennt sich ein anderer Programmierer mit Linux genug aus, um die automatischen Buildskripte so anzupassen, dann die /Xmx12M Option nur bei den Versionen benutzt wird, die für den PDA bestimmt sind. Mik? Kalli? Bilbowolf?
Ich bin mir nicht ganz sicher, aber ich vermute, dass es genügt, die Buildskripte im SVN anzupassen, damit sie automatisch verwendet werden.

Schöne Grüße,
Pfeffer.
 

blackeye501

Geocacher
Wenn es am /Xmx12M liegt, ist doch kein build-Skript zu ändern.
Es ist nur ein Parameter beim Ausführen des Java-Interpreters.
Ich weiß jetzt nicht wie Cachewolf unter Linux (Java-Version) gestartet wird, aber ich nehme mal an so:
Code:
java -cp CacheWolf.jar ewe.applet.Applet CacheWolf.CacheWolf
Jetzt einfach /Xmx12M als Parameter hinzu, und Java wird angewiesen mindestens 12MB heap memory zu Verfügung zu stellen.
Probier mal
Code:
java -cp CacheWolf.jar ewe.applet.Applet /Xmx12M CacheWolf.CacheWolf
 

MiK

Geoguru
blackeye501 schrieb:
Wenn es am /Xmx12M liegt, ist doch kein build-Skript zu ändern.
Es ist nur ein Parameter beim Ausführen des Java-Interpreters.
Ich weiß jetzt nicht wie Cachewolf unter Linux (Java-Version) gestartet wird, aber ich nehme mal an so:
Code:
java -cp CacheWolf.jar ewe.applet.Applet CacheWolf.CacheWolf
Jetzt einfach /Xmx12M als Parameter hinzu, und Java wird angewiesen mindestens 12MB heap memory zu Verfügung zu stellen.
Probier mal
Code:
java -cp CacheWolf.jar ewe.applet.Applet /Xmx12M CacheWolf.CacheWolf

Nicht direkt im buildscript, aber eben beim Schnüren der Pakete. Der Parameter steckt irgendwo im .jar-file glaube ich.

Und da soll er jetzt für alle nicht-PDA-Plattformen raus?

Keine Ahnung, wo das passiert. Aber vielleicht kann ich bei Gelegenheit mal danach fahnden.
 

pfeffer

Geowizard
Es ist ihm etwas zugestoßen, ja :-( Was ist aber unklar.

Das Buildskript muss so angepasst werden, dass es 2 .jnf Files verwendet. Eins für die PDA-Version mit der Option (denn sonst fordert ewe auf dem PDA nur 4MB an und das ist zu wenig) und eins für die, die nicht auf dem PDA laufen.
Evtl. muss man 2 .ewe erstellen, eines mit und eins ohne der Option -Xmx12M

Gruß,
Pfeffer.
 

Kalli

Geowizard
Der Parameter steckt im .jnf-File, wenn man in Jewel auf Command-Line-Options (oder so ähnlich, habe es geade nicht da) geht, kann man dort etwas eintragen oder löschen. Dann noch "hinten" ausgewählt, für welche Plattformen das Ganze erstellt werden soll und mit einem entsprechenden Namen speichern. Der Aufruf im buidscript ist glaube ich ziemlich selbsterklärend. Ich habe allerdings keine Ahnung, was der nightly build alles treibt. Eigentlich müsste man sich nur mal eine BE anschauen, was neben dem jar bzw. exe noch so alles an Dateien in dem zip mit drin ist und so ein Archiv nach dem Build herstellen.

Ich bin leider momentan ziemlich im Stress, den Post schreibe ich auch noch im Büro.
 

Bilbowolf

Geowizard
In den auf Berlios veröffentlichten BEs wird der Build angepasst durchgeführt. Dort sollte es also passen. Für die Releases auf jeden Fall auch.

Für die nightly builds kann ich nichts ändern, da kein Zugriff darauf.
 

blackeye501

Geocacher
Ok jetzt versteh ich wo Ihr den Parameter übergebt. Wobei eine unterscheidung zwischen den Versionen grundsätzlich nicht notwendig ist. /Xmx12M gibt den mindestens zur Verfügung gestellten heap memory an (wenn genug speicher vorhanden ist wird auch mehr verwendet)

Das einzige Problem, dass ich bisher sehe ist beim Aufruf der JAVA Version. Da im build-skript /xmx 12M stehen muß, damit die Windows und PocketPC läuft, gibt es ein Problem in der Batch-Datei der Java-Version. Dort muß dann der Parameter von
Code:
/xmx 12M
nach
Code:
/xmx12M
geändert werden. (am einfachsten durch nachträgliches ändern in der batch-Datei) Ansonsten kommt der bekannte Fehler "class not found: 12M".

Wobei ich jetzt nicht weis, ob in den nightly builds der Parameter noch drinnen ist oder nicht. Auf jeden Fall ist es bei Benutzung der JAVA-Version egal, da man diese ja von Hand mit dem Parameter /Xmx12M starten kann:

Code:
java -cp CacheWolf.jar ewe.applet.Applet /Xmx12M CacheWolf.CacheWolf

Edit: Abstand bei /xmx nicht sichtbar
 
Oben