You Are Here:

Community: Developer Discussion Boards

#1 Old Problem with CreateImage - 2003-04-07, 13:32

Join Date: Mar 2003
Posts: 2
maghal
Offline
Registered User
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
Reply With Quote

#2 Old 2003-06-06, 16:07

Join Date: Jun 2003
Posts: 9
dynamitemobile
Offline
Registered User
I've had exactly the same problem- has anyone come across a solution or workaround for this?

Thanks

Ian
Reply With Quote

#3 Old 2003-06-06, 21:00

Join Date: Jun 2003
Posts: 9
dynamitemobile
Offline
Registered User
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
Reply With Quote

#4 Old 2003-06-07, 15:06

Join Date: Jun 2003
Posts: 1
ryangilbertgarcia
Offline
Registered User
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...
Reply With Quote

#5 Old 2003-06-07, 20:14

Join Date: May 2003
Posts: 151
Danack
Offline
Regular Contributor
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;
}
Reply With Quote

#6 Old 2003-06-09, 12:43

Join Date: Apr 2003
Posts: 49
Location: Kiev, Ukraine
cryptoalex
Offline
Registered User
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.
Reply With Quote

#7 Old 2003-06-09, 17:50

Join Date: Jun 2003
Posts: 9
dynamitemobile
Offline
Registered User
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
Reply With Quote

#8 Old 2003-06-10, 00:52

Join Date: Mar 2003
Posts: 8
rmmc
Offline
Registered User
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)
Reply With Quote

#9 Old Re: Problem with CreateImage - 2006-10-18, 13:44

Join Date: Oct 2006
Posts: 8
angeldt
Offline
Registered User
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 http://www.mikeullrich.com/



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.
.
Reply With Quote

#10 Old Re: Problem with CreateImage - 2006-10-18, 13:48

Join Date: May 2003
Posts: 151
Danack
Offline
Regular Contributor
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.
Reply With Quote

#11 Old Re: Problem with CreateImage - 2006-10-19, 13:43

Join Date: Oct 2006
Posts: 8
angeldt
Offline
Registered User
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.
Reply With Quote

#12 Old Re: Problem with CreateImage - 2006-10-19, 15:38

Join Date: Oct 2006
Posts: 8
angeldt
Offline
Registered User
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.
Reply With Quote
Reply « Previous Thread | Next Thread »
Display Modes
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules

You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Forum Jump

Rate This

 
Bookmark this page: DeliciousDiggFacebookGoogleYahooStumbleUponRedditDiigoTechnocratiTwitter  Share this page Share this page Print this Page Print this page Invite a friend Invite a friend
京ICP备05048969号    Email Newsletters Press Terms & Conditions Privacy Policy Sitemap Contact Us © 2009 Nokia 
RDF Facets: qdcZidentifierQSxhttpE3aE2fE2fdiscussionE2eforumE2enokiaE2ecomhttpE3aE2fE2fdiscussionE2eforumE2enokiaE2ecomE2fforumE2fshowthreadE2ephpE3ftE3d18645X qdcZtypeQUqfnZE45E78cludedFromGeneralE4cistingsQ qdcZtypeQUqfntypeZCommunityContentQ qdcZtypeQUqfntypeZE44iscussionQ qdcZtypeQUqfntypeZE44iscussionContentQ qdcZtypeQUqfntypeZE52esourceQ qdcZtypeQUqfntypeZWebpageQ qdcZtypeQUqmarsZManagedE52esourceQ qdcZtypeQUqwebZInformationE52esourceQ qdcZtypeQUqwebZPageQ qdcZtypeQUqwebZE52esourceQ qdcZtypeQUqrdfsZE52esourceQ qfnZtopicQUqfnTopicZentertainmentQ qfnZtopicQUqfnTopicZj2meQ qfnZtopicQUqfnTopicZjavaQ qfnZtopicQUqfnTopicZmediaQ qfnZtypeQUqfntypeZCommunityContentQ qfnZtypeQUqfntypeZE44iscussionQ qfnZtypeQUqfntypeZE44iscussionContentQ qfnZtypeQUqfntypeZE52esourceQ qfnZtypeQUqfntypeZWebpageQ qmarsZlanguageQUxhttpE3aE2fE2fswE2enokiaE2ecomE2flanguageE2d1E2fenX qrdfZtypeQUqfnZE45E78cludedFromGeneralE4cistingsQ qrdfZtypeQUqfntypeZCommunityContentQ qrdfZtypeQUqfntypeZE44iscussionQ qrdfZtypeQUqfntypeZE44iscussionContentQ qrdfZtypeQUqfntypeZE52esourceQ qrdfZtypeQUqfntypeZWebpageQ qrdfZtypeQUqmarsZManagedE52esourceQ qrdfZtypeQUqwebZInformationE52esourceQ qrdfZtypeQUqwebZPageQ qrdfZtypeQUqwebZE52esourceQ qrdfZtypeQUqrdfsZE52esourceQ