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

cw-ppc2003.jnf > rev 1.1.2555 macht Probleme

maierkurt

Geowizard
Ich habe jetzt bestimmt zwei Stunden herumprobiert:
Ich habe die "offiziellen" NBs und auch meine eigenen probiert: Die Version der cw-ppc2003.inf ab rev 1.1.2556 macht auf meinem HD2 (WinMob 6.5) Probleme bei der MovingMap. Es erscheint dann die Fehlermeldung: "Nicht genug Ressourcen verfügbar" [...] "Versuchen Sie einige Programme zu schließen" (oder so ähnlich)
Ich weiß jetzt nicht genau, ob nur der Xmx 12M-Schalter verändert wurde. Mit mehr als 12M funktioniert die MM bei mir nicht mehr. (Ich habe die Werte 24, 32 und 64 probiert)

Wie sieht es denn bei Euch aus?


Gruß, maierkurt
 

pfeffer

Geowizard
wäre nett gewesen, wenn Du in der svn-commit-nachricht angegeben hättest, welche Einstellung Du nun genau damit getestet hast.

Gruß,
Pfeffer.
 

pfeffer

Geowizard
Anregung: vielleicht auch andere Memory-Einstellungen außer -Xmx testen.

Gruß,
Pfeffer.
 
OP
M

maierkurt

Geowizard
pfeffer schrieb:
Anregung: vielleicht auch andere Memory-Einstellungen außer -Xmx testen.

Gruß,
Pfeffer.

Würde ich sehr gerne. Wie geht das? Ich habe da nicht so die Ahnung.
Meine Vorgehensweise war bisher immer:

1. Aufrufen der runjewel.bat und laden der der Datei "cw-ppc2003.jnf
file.php







2. Klick
file.php




3. Modifizieren des Xmx Werts
file.php









Wo kann ich noch etwas ändern?

Gruß, maierkurt












.
 

Anhänge

  • cw_1.png
    cw_1.png
    38,5 KB · Aufrufe: 524
  • cw_2.png
    cw_2.png
    45,8 KB · Aufrufe: 524
  • cw_3.png
    cw_3.png
    60,7 KB · Aufrufe: 524

pfeffer

Geowizard
ja, da ist schon die richtige Stelle. Nur dachte ich gibt es vielleicht weitere Optionen, die das Memory-Verhalten der Ewe-Vm beeinflussen.
Ich habe etwas herum gesucht und nun immerhin die Stelle im Ewe-VM-Source-code gefunden, die die Commandozeilen-Optionen interpretiert:
Code:
static WObject startApp(WCHAR *cmdLine, BOOL *alreadyRunning,int level)
	{
	int vmStackSize, nmStackSize, classHeapSize, objectHeapSize;
	int i;
	WCHAR **words;
	WCHAR *className = mainClassName;
	WCHAR c;
	int num;
	WObject ret;
//MLB
	vmStackSize = 10000;
	nmStackSize = 100;
	//
	// The class heap uses virtual memory so memory is only used when needed.
	//
	classHeapSize = 500000;
	objectHeapSize = 32000;
	uniCopy(L"eWe",g_windowTitle,50);
	if (level == 0) programDir[0] = 0;
/*
	vmStackSize = 1500;
	nmStackSize = 300;
	classHeapSize = 14000;
	objectHeapSize = 8000;
*/
	className = 0;
	*alreadyRunning = 0;

	num = parseLine(cmdLine,NULL);
	if (num == 0){
		WCHAR *def = DefaultApplication;
		WCHAR *t2 = mMalloc(sizeof(WCHAR)*50);
		uniCopy(def,t2,unilen(def)+1);
		cmdLine = t2;
		num = 1;
	}else if (num == 1 && unicmp(cmdLine,L"--") == 0){
		doPreload(alreadyRunning);
		return 0;
	}else if (num == 1 && unicmp(cmdLine,L"-") == 0){
		doUnload();
		return 0;
	}
	words = mMalloc(sizeof(WCHAR *)*num);
	parseLine(cmdLine,words);

	for (i = 0; i<num; i++){
		int value = 
			i<num-1 ? getValue(words[i+1]):0;
		if ((*words[i] == '/' || *words[i] == '-') && !isWarp(words[i])) {
			//
			// Not a EWE file, but starts with '/' or '-'
			// Has the start class been determined, if so then this must
			// be a parameter for the application, not the VM.
			// However we should check if it is "/-" or "--".
			//
			c = *(words[i]+1);
			if (className != 0){
				if (c == '-') i++; //Skip over "/-" or "--".
				break;
			}
			if (i == num-1) 
				if (!strchr("zrpnmsoO-",c)) break;
			i++;
			if (c == '-') 
				break;
			switch(c){
				case 'b': uniCopy(words[i],g_windowTitle,50); break;
				case 'c': 
					if (uniCompare(words[i-1]+1,-1,L"cp",2) == 0){
						int len = unilen(words[i])+1;
						classPath = mMalloc(sizeof(WCHAR)*len);
						uniCopy(words[i],classPath,len);
						break;
					}
					if (value > classHeapSize) classHeapSize = value; break;
				//case 's': if (value > vmStackSize) vmStackSize = value; break;
				case 't': if (value > nmStackSize) nmStackSize = value; break;
				case 'X': 
					if (uniCompare(words[i-1]+1,-1,L"Xmx",3) == 0){
						maxMemorySize = value; if (maxMemorySize < 1024) maxMemorySize = 1024; break;
					}else if (uniCompare(words[i-1]+1,-1,L"Xms",3) == 0){
						objectHeapSize = value; if (objectHeapSize < 1024) objectHeapSize = 1024; break;
					}
				case 'w': g_mainWinWidth = value; break;
				case 'h': g_mainWinHeight = value; break;
				case 'd': uniCopy(words[i],programDir,unilen(words[i])+1); programDirDefined = 1; break;
				case 'x': uniCopy(extPath,programDir,unilen(extPath)+1); break;
				case 'r': VmFlags |= VM_FLAG_IS_MOBILE; i--; break;
				case 'z': VmFlags |= VM_FLAG_IS_MONOCHROME; i--; break;
				case 'k': VmFlags |= VM_FLAG_NO_MOUSE_POINTER|VM_FLAG_NO_KEYBOARD; i--; break;
				case 'p': VmFlags |= VM_FLAG_NO_MOUSE_POINTER|VM_FLAG_NO_KEYBOARD; SimulateSip = 0x1; i--;
					if (g_mainWinWidth == 0 && g_mainWinHeight == 0)
						g_mainWinWidth = 240, g_mainWinHeight = 320;
					break;

				case 's': 
					VmFlags |= VM_FLAG_HAS_SOFT_KEYS|VM_FLAG_NO_WINDOWS|VM_FLAG_NO_MOUSE_POINTER|VM_FLAG_NO_KEYBOARD|VM_FLAG_NO_PEN|VM_FLAG_USE_NATIVE_TEXT_INPUT; i--; 
					if (g_mainWinWidth == 0 && g_mainWinHeight == 0)
						g_mainWinWidth = 176, g_mainWinHeight = 220;
					break;

				case 'l': uniCopy(words[i],localeData,unilen(words[i])+1); break;
				case 'n': VmFlags |= VM_FLAG_NO_WINDOWS; i--; break;
				case 'o': VmFlags |= VM_FLAG_ROTATE_SCREEN; i--; break;
				case 'O': VmFlags |= VM_FLAG_COUNTER_ROTATE_SCREEN; i--; break;
				case 'm': VmFlags |= VM_FLAG_IS_LOW_MEMORY; i--; break;
			}
		}else{
			if (!isWarp(words[i])){
				if (className == 0)
					className = words[i];
				else 
					break;
			}else{
				if (alreadyMapped(words[i])) continue;
				if (tryToMemMapFile(words[i],1) && (level == 0)){
					WCHAR * p = words[i]+unilen(words[i])-1;
					WCHAR * e = p;
					if (eweFile[0] == 0) uniCopy(words[i],eweFile,MAX_PATH);
					*p-- = 'n';
					*p-- = 'u';
					*p-- = 'r';
					e = p;
					for (;p>words[i] && *p != '/' && *p != '\\'; p--);
					if (p >= words[i] && (*p == '/' || *p == '\\')) *p = 0, p++;
					if (programDir[0] == 0)
						if (p == words[i]+1)
							uniCopy(L"\\",programDir,2);
						else if (p != words[i])
							uniCopy(words[i],programDir,unilen(words[i])+1);
						else
							uniCopy(L".\\",programDir,3);
					inWarp = (WCHAR *)mMalloc(sizeof(WCHAR)*(e-p+1));
					uniCopy(p,inWarp,e-p+1);
					inWarp[e-p] = 0;
					if (className == 0){
						unsigned int len;
						char * asciiPath = unicodeToTempAscii(p,-1);
						char * command = (char *)loadFromMem(asciiPath,strlen(asciiPath),&len,NULL);
						if (command != NULL){
							WObject ret;
							WCHAR *cl = (WCHAR *)mMalloc(sizeof(WCHAR)*(len+1));
							asciiToUnicode(command,cl,len+1);
							cl[len] = 0;
							//MessageBox(NULL,cl,TEXT("Command!"),MB_OK);
							takeArguments = (i == num-1);
							ret = startApp(cl,alreadyRunning,1);
							//free(cl); Don't free it. It may be used for arguments.
							className = mainClassName;
							//return ret; Don't continue parsing original line.
						}
					}
				}
			}
		}

	}
Quelle: http://www.ewesoft.com/Downloads/Ewe149-Source-Win32.zip darin Datei nmwin32_b.c ab Zeile 3322.

Vielleicht hilft das ja irgendwie.
EDIT: Ich lese daraus z.B., dass die folgenden Optionen interessant sein könnten:
* -t nmStackSize
* -c classHeapSize
* -Xmx maxMemorySize
* -Xms objectHeapSize

Gruß,
Pfeffer.
 

MiK

Geoguru
Wenn wir verschiedene Speichereinstellungen testen wollen, sollten wir von der gleichen Revision verschiedene Varianten bauen und diese gemeinsam zum Download und Testen anbieten. Einfach stillschweigend im SVN zu drehen und zu warten bis einer schreit, halte ich für keinen guten Weg.
 

arbor95

Geoguru
maierkurt schrieb:
Ich habe jetzt bestimmt zwei Stunden herumprobiert:
Ich habe die "offiziellen" NBs und auch meine eigenen probiert: Die Version der cw-ppc2003.inf ab rev 1.1.2556 macht auf meinem HD2 (WinMob 6.5) Probleme bei der MovingMap. Es erscheint dann die Fehlermeldung: "Nicht genug Ressourcen verfügbar" [...] "Versuchen Sie einige Programme zu schließen" (oder so ähnlich)
Ich weiß jetzt nicht genau, ob nur der Xmx 12M-Schalter verändert wurde. Mit mehr als 12M funktioniert die MM bei mir nicht mehr. (Ich habe die Werte 24, 32 und 64 probiert)

Wie sieht es denn bei Euch aus?


Gruß, maierkurt
Danke für die Tests!

Bei ARM steht der Wert übrigens auf 6.
 
OP
M

maierkurt

Geowizard
araber95 schrieb:
Bei ARM steht der Wert übrigens auf 6.
Diesen Wert habe ich jetzt auch bei mir eingestellt. Die MM funktioniert jetzt sogar! (Ist zwar langsam, da ich große Kacheln habe)
Soll ich noch andere Werte ausprobieren?


Gruß, maierkurt
 

arbor95

Geoguru
maierkurt schrieb:
araber95 schrieb:
Bei ARM steht der Wert übrigens auf 6.
Diesen Wert habe ich jetzt auch bei mir eingestellt. Die MM funktioniert jetzt sogar! (Ist zwar langsam, da ich große Kacheln habe)
Soll ich noch andere Werte ausprobieren?


Gruß, maierkurt
Weiter runter macht wohl andere Probleme.

Wie weit kannst du hochgehen und die MM geht immer noch?

Dann würde ich den Wert ins svn übernehmen!

(Geschwindigkeit. Wenn die Flächen gefüllt werden ist ja erst mal egal, wann!)
 

pfeffer

Geowizard
Das Speicher-Management findet sich in ewe_vm.c ab Zeile 6870.

Es ist ja irgendwie seltsam, dass eine kleinere Zahl hier besser zu sein scheint.
Vielleicht kann mal jemand versuchen herauszufinden, welche Exception genau auftritt und am besten auch mit Zeilennummern im Ewe-Code, damit man im Ewe-Source-Code gucken kann, wann die geworfen wird.

Gruß,
Pfeffer.
 
OP
M

maierkurt

Geowizard
pfeffer schrieb:
Vielleicht kann mal jemand versuchen herauszufinden, welche Exception genau auftritt
Es trifft diese Exception auf: (den Xmx Schalter habe ich einfach mal auf 64 gesetzt)
Code:
SystemResourceException in MovingMap.java Zeile 1705
ewe.sys.SystemResourceException: System could not create bitmap
	at ewe.fx.Image._nativeCreate(Image.java:<native method>)
	at ewe.fx.Image.decodeFrom(Image.java:376)
	at ewe.fx.Image.decodeFrom(Image.java:284)
	at ewe.fx.Image.<init>(Image.java:1408)
	at ewe.fx.Image.<init>(Image.java:1424)
	at CacheWolf.navi.MapImage.<init>(MapImage.java:30)
	at CacheWolf.navi.MovingMap.setMap(MovingMap.java:1658)
	at CacheWolf.navi.MovingMap.setBestMap(MovingMap.java:1463)
	at CacheWolf.navi.MovingMap.loadBestMap(MovingMap.java:977)
	at CacheWolf.navi.MovingMap.updatePosition(MovingMap.java:988)
	at CacheWolf.navi.MovingMap.myExec(MovingMap.java:395)
	at CacheWolf.MainTab.SwitchToMovingMap(MainTab.java:350)
	at CacheWolf.navi.GotoPanel.switchToMovingMap(GotoPanel.java:313)
	at CacheWolf.navi.GotoPanel.onEvent(GotoPanel.java:373)
	at ewe.ui.Control.postEvent(Control.java:1380)
	at ewe.ui.Control.notifyAction(Control.java:1795)
	at ewe.ui.ButtonControl.fullAction(ButtonControl.java:156)
	at ewe.ui.ButtonControl.fullAction(ButtonControl.java:148)
	at ewe.ui.ButtonControl.penReleased(ButtonControl.java:123)
	at ewe.ui.Control.penClicked(Control.java:2376)
	at ewe.ui.Control.onPenEvent(Control.java:2144)
	at ewe.ui.Control.onEvent(Control.java:1439)
	at ewe.ui.Control.postEvent(Control.java:1375)
	at ewe.ui.Window.doPostEvent(Window.java:1171)
	at ewe.ui.Window$windowThread.run(Window.java:771)
	at ewe.sys.mThread.run(mThread.java:250)

pfeffer schrieb:
und am besten auch mit Zeilennummern im Ewe-Code, damit man im Ewe-Source-Code gucken kann, wann die geworfen wird.
Ähm, ja. DAS übersteigt im Moment leider meine Fähigkeiten


Gruß, maierkurt

EDIT: [qoute="araber95"]Die NPE in fillwhite ist "nur" ein Folgefehler, da die Karte wegen resmangel nicht geladen werden konnte.[/quote]
Habs rausgenommen.
 

arbor95

Geoguru
Die NPE in fillwhite ist "nur" ein Folgefehler, da die Karte wegen resmangel nicht geladen werden konnte.
 

pfeffer

Geowizard
@maierkurt: genau so eine Ausgabe habe ich gemeint. - danke!

Habe mir dazu den passenden ewe-code in C rausgesucht.
Wenn ich das richtig interpretiere, dann wird für die Bilder nicht der normale Heap der VM benutzt, sondern entweder per malloc(size), per CreateCompatibleBitmap(handle, width, hight) oder CreateDIBSection(..) direkt vom Betriebssystem (Windows) Speicher angefordert (ewe.fx.Image._nativeCreate ist in C ImageCreate in der Datei nmwin32_c.c und wirft die von maierkurt zitierte Exception, die hier über returnBmpException() erzeugt wird. ImageCreate ruft InitImage auf, welches entweder über CreateCompatibleBitmap oder über CreateDIBSection Speicher direkt vom Betriebssystem anfordert.)
Das erklärt auch, warum -Xmx nicht zu groß sein darf, weil dann der noch freie, vom Betriebssystem verwaltete Speicher kleiner wird.
Der Heap ist für das Betriebssystem ein großes Objekt, die darin abgelegten Objekte verwaltet die Ewe-VM selbst (wobei die Objekte selbst von unten auf den Heap abgelegt werden und die Verwaltungsinformationen für die Objekte von Oben). Bei Bedarf vergrößert die Ewe-VM den Heap, verwendet dazu aber (wenn man Pech hat) ein doofes Verfahren: als erstes fordert sie vom Betriebssystem Speicher an, der die neue Größe hat. Dann kopiert sie den Inhalt des Heaps dorthin. Das bedeutet, mehr als die Hälfte des RAM wird die Ewe-VM als Heap kaum nutzen können.
Die SystemResourceException verweist offenbar darauf, dass nicht der Heap zu klein ist, sondern das Betriebssystem den angeforderten Speicher nicht zur Verfügung stellen konnte. Das könnte der Unterschied zum OutOfMemeoryError sein.

EDIT:
Eine weitere wichtige Konsequenz ist: die Garbage Collection funktioniert für Bilder nicht: Bilder müssen unbedingt per image.free() dealloziert werden. Um das debuggen zu können hat die Klasse ewe.fx.Image ein public static int numImages, der die Anzahl der Bilder angibt, die erzeugt wurden, aber nicht mittels image.free() dealloziert wurden.

Gruß,
Pfeffer.
 

pfeffer

Geowizard
ich sehe vorallem 2 Sachen:

1. Der Parameter -Xmx, der die Ewe-VM-Heapgröße angibt, sollte so groß gewählt werden, dass alle Objekte da hineinpassen, außer Bilder. Da die Bilder in dem Teil des RAMs abgelegt werden, der neben dem Heap noch übrig ist, muss bei der Festlegung der Heap-Größe außerdem darauf geachtet werden, dass noch genug RAM für alle Bilder zur Verfügung steht.

2. Man sollte mal die MovingMap beobachten, ob bei allen Bildern der Bildspeicher per image.free() auch wieder freigegeben wird. Das kann man, in dem man den Bildspeicherzähler Image.numImages beobachtet. Kandidaten dafür könnten das Zoomen und die "weiße Fläche-füllen"-Funktion sein, denn dabei wurde ja mehrfach von Speicherproblemen berichtet.

Gruß,
Pfeffer.
 

pfeffer

Geowizard
Ich dachte, vielleicht kann ich Euch beim experimentieren unterstützen - mehr wollte ich nicht.

Gruß,
Pfeffer.
 
Oben