Serious memory leak bug in J9?

[Troels Jakobsen]

It appears that J9 allocates memory and refuses to deallocate it.
I've made a simple demo midlet to illustrate. Code is below.
It's simply two canvases which alternately are brought to the
foreground when the user taps the screen.

Every time I tap the screen approx. 100 KB of storage space
(not heap) disappears (evidenced by the PDA's memory settings).
Calling System.gc() makes no difference - it doesn't seem to be
a problem with object deallocation. Eventually the midlet freezes
when no more storage is available.

I use the J9 version bundled with WSDD 5.7.1 on an iPaq 3715
w. Windows Mobile 2003 SE. I've tried compiling with both
Sun's WTK2.2 and WSDD 5.7.1.

Is this an unsupported platform for J9? Or is there another reason
for this IMHO very serious error? The problem also appears on
Qtek 1010 and Qtek 2020 and other models.

Thanks
Troels

--------------- Application ---------------

import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;

public class Application extends MIDlet
{
private static Canvas1 canvas1;
private static Canvas2 canvas2;
private static boolean initDone = false;
private static Display display;

protected void startApp() throws MIDletStateChangeException {
if (!initDone) {
display = Display.getDisplay(this);
canvas1 = new Canvas1();
canvas2 = new Canvas2();
displayCanvas1();
initDone = true;
}
}

protected void pauseApp() {
}

protected void destroyApp(boolean flag) throws MIDletStateChangeException
{
}

public static void displayCanvas1() {
display.setCurrent(canvas1);
}

public static void displayCanvas2() {
display.setCurrent(canvas2);
}
}

--------------- Canvas1 ---------------

import javax.microedition.lcdui.*;

public class Canvas1 extends Canvas
{
protected void pointerPressed(int x, int y) {
Application.displayCanvas2();
}

protected void paint(Graphics g) {
g.drawString("Canvas 1", 10, 10, Graphics.LEFT | Graphics.TOP);
}
}

--------------- Canvas2 ---------------

import javax.microedition.lcdui.*;

public class Canvas2 extends Canvas
{
protected void pointerPressed(int x, int y) {
Application.displayCanvas1();
}

protected void paint(Graphics g) {
g.drawString("Canvas 2", 10, 20, Graphics.LEFT | Graphics.TOP);
}
}

[Jon Eschinger]

Windows Mobile 2003 SE will be supported on 5.7.2 which will be
available shortly. Don't know exact date, but soon.

Jon

[Troels Jakobsen]

That's nice to hear.

HOWEVER, the problem also occurs on such PDAs as:
- iPaq 2210 (WM2003 non-SE, 4.20.1081 build 13100)
- Qtek 1010 (WM2003 non-SE, 4.20.0 build 13349)

So it appears to me that this is a general bug! And a very serious
one, if you, like my company, have a midlet where you navigate
between lots of canvases.

Troels

BTW: Is there a page somewhere listing the platforms J9 supports?

"Jon Eschinger" <jon_es...@us.ibm.com> wrote in message
news:d2d823$43f4$1...@news.boulder.ibm.com...

[blu...@digitalmaze.gr]

Jon, do you also confirm that this is a bug of WSDD 5.7.1? Also, do you know if it will be addressed in 5.7.2.?

Thanks

[john....@gmail.com]

Don't know if this helps or not, but on the Sony Clie running your app
shows a chunk of 4k disappearing every 4th iteration (or so), but then
when it gets down to zero, garbage collection occurs and heap goes back
up to about 100k.

I still can't get ANY midlets running on my iPAQ, not even MIDlet HQ or
the sample Golf Scores MIDlet.

[john....@gmail.com]

I fixed my MIDlet problems by removing the other (ppro10) VM. Don't
know why that had anything to do with it, but apparently it did. Now
I'm testing your MIDlet, and it starts with about 800K free, dropping
4k or so every time I tap the screen (I added
Runtime.getRuntime().freeMemory() to the "Canvas" strings) until it
gets below about 400K, at which point it locks up. I can close the app
at that point, and do just about anything else but run a MIDlet. I have
to soft-reset in order to restore full operation.

[Troels Jakobsen]

I sent a problem report to IBM support concerning this memory leak,
and they have confirmed the problem. I will keep you posted whether
they produce a fix.

In the meantime I deployed the new WEME 5.7.2 today (on a
WM 2003 SE iPaq 3715), and while the leak still exists, it is now
much smaller. Instead of losing 100 KB of storage every time a
canvas is set to the foreground, only 2 KB is now lost.

I have yet to test it on other, non WM 2003 SE PocketPCs, but I
presume they will show the same improvement.

Troels

[blu...@digitalmaze.gr]

Please do that. Also i have deployed WEME 5.7.2 and i have noticed that the leak is improved.

While my application was running perfectly under WEME 5.7.1 I am facing some problems with WEME 5.7.2.

I am suspecting that it has something to do with Custom Items and their paint events. I have developed a component that I am placing it on each form. I will investigate it and get back soon.

Thanks.