Problem with CreateImage

Hi!
I am trying to develop an application that shows maps on a nokia7650. The problem is that it throws a IllegalArgumentException after I've called the CreateImage method for about 30 times. Even if I call the CreateImage with exactly the same arguments each time, it fails when I have called it about 30 times.

If anybody know anything about this issue or has the same problem please answer.

/Magnus from Sweden

I've had exactly the same problem- has anyone come across a solution or workaround for this?

Thanks

Ian

To expand on the problem:

I've got a graphically intensive game on the Nokia 7650 that uses a lot of images which are loaded from .png images. After the game has been run it returns to the in game menu, and then you can start it again. Usually on the the 3rd or 4th time the game is started, the application stops whilst trying to call
createImage(byte [], int, int)

I've now changed the createImage(byte[], int, int) call to the equivalent createImage(String) call as all of my images are saved as seperate pngs in the jar. It now throws an IOException after a while, saying "resource not found" - even though the image has loaded without problems a few times before.

If an exception is thrown, I then load the same file into a byte array: this always loads fine and I know the data is ok as I've checksummed them and it's still ok.
I then use createImage(byte[], int, int) to try to create the image, but it throws an IllegalArgumentException, so I'm back to the start of the problem...

The extra strange thing is that I've run it through 3 times just and each time it's come up against a problem on a different .png file.

Any help or ideas would be greatly appreciated. I've been banging my head against a wall for 3 days on this problem now.

Ian

I had a similar problem before; the problem was that i used fireworks mx to create my png images, and for some reason, i couldn't load the images. fireworks may be storing other information on the png's maybe, that the image couldn't be recognized... images i created using photoshop 7.0 though worked fine...

Sounds like you're all running out of memory. Use this function to see if you're free memory is dropping repeatedly....if so you've got a memleak.

public static long FreeMemory()
{
long free;

Runtime.getRuntime().gc();

free = Runtime.getRuntime().freeMemory();
System.out.println( "Free memory is: " + free );

return free;
}

Hi!

freeMemory won't help as memory is dynamically allocated on series60 phones from available RAM and free memory amount is changing dynamically.

BTW there is the same problem on 3650. Calling createImage for about 20 times on 2-Kb PNG leads to IOException.
Seems to be GC bug.

Yeah, it's definately not available memory that's causing a problem. And I've tried saving the images out using ImageOptimiser, ACDsee and Pro Motion, but I still get the same result.

Looks like it's time for a drastic rethink...

Cheers,

Ian

I'm having the same problems as all the others and from my experience it is not a memory problem.
I controlled the flow of memory and it just crashes when I try to load a 600 bytes image when I have 80k free... (this on the 7210 emulator)

I´m developing a J2ME client program as part of a large project in which I need to create a lot (hundreds) of images. When I run it on

an emulator or a Samsung phone everything goes fine. But, when I use a Nokia I end up running out of memory, because something is not

being freed; and it is actually freed on Samsungs and the emulator. This can be easily observed using Symbian´s MemoryMonitor; or the

advanced MemoryMonitor available in [url]http://www.mikeullrich.com/[/url]



I have seen that the "createImage" method uses native memory from symbian, which should actually be freed. I don´t know wether this

problem is of Symbian or Nokia´s KVM implementation.



Does anyone know of any similar problem(s) with nokia phones and memory not being liberated? Anyone can shed some light on this?



Thanks in advance.
.

Which Nokia phones have you tried it on?

There are some memory leaks in reading files on some Nokia series 60 devices, which means you need to cache the data rather than reloading it.


>as part of a large project in which I need to create a lot (hundreds)

That sounds like a bad idea. I'm sure a lot of phones would be happier if you had much fewer images by packing the images together and then just set the clip region to draw a part of that image.

Hola, ya he encontrado la solución al problema. Nokia no tiene perdidas de memoria al crear imagenes. El problema es el siguiente, si creas imánes, tienes que estar 100% seguro de que el objeto que apunta a esa imagen se libera. En muchos télefonos estos objetos si se liberan, pero en los Nokia, tienes que asegurarte de poner las referencias a null explicitamente. En nuestra aplicación teniamos muchas referencias cruzadas. Pues para conseguir que finalmente se liberase todos los recursos hemos tenido que ir limpiando las referencias una por una. Se puede probar que efectivamente Nokia no pierde memoria al crear imagenes si estas se desreferencia correctamente mediante un Midlet de prueba y el Memory Monitor. Todo el problema biene de cuando no se libera la referencia en Java hacia el objeto de memoria, entonces symbian conserva de forma nativa la representanción en memoria de la imagen (que ocupa mucho mas que la representación del objeto en Java, por eso decrece mucho mas rápido la memoria libre que le va quedando al teléfono que el heap de la aplicación). Todo esto surge debido a que la KVM es mucho menos inteligente con respecto a liberación de recursos que KVM de Samsung o del emulador.

Como conclusión decir que NOKIA no tiene un bug de memoria, sino que el recolector de basura de la KVM es mucho menos inteligente que otros. Por lo que aseguraros de que todas las posibles referencias a las imagenes son null, y no queda ninguna referencia colgada por ningún lado, ni directa ni indirectamente.

Hello,



I have just found the solution for this problem. Nokia has no memory leaks when creating images. The problem is: if you create images, then

you have to be fully sure that the object pointing to that image will be liberated. In most phones these objects are actually liberated, but

in Nokia you have to make sure you explicitly point every reference to NULL. In our app. we had a lot of cross references and, in order to get

every resource liberated, we have needed to clean references one by one. You can then confirm that no memory leaks exist on Nokia when creating

images if you dereference them as explained before. All of the problem comes when you do not dereference the java references to the object:

symbian keeps the image´s memory representation natively, and this takes up much more space than java´s object representation; that´s why the

phone´s free memory decreases much faster than the heap. All this is due to Nokia´s KVM being much less "intelligent" regarding to resource

freeing than it is on Samsung phones or an Emulator.



In brief: Nokia has no memory bugs, but a much less intellingent KVM garbage collector than others. So, make sure you point to null every

unused reference, and you don´t leave any "hung up" reference, either directly or indirectly.