7 replies to this topic

[BloodWarrior]

Heyas So I have been developing a small game for myself on my Nokia 6230i and everything is fine there. However I just got a brand new Nokia 6300 and when I tried my game there it crashes with an Out of Memory exception during the midlet initialisation. Does anyone know what is going on? how can the game work fine on 6230i and not on a new 6300. Also I havent got a single idea on how to debug this. I usually debug on the default emulator and then on the nokia 6230i sdk emulator (for more precision as its slower to load). Obviously these are fine, as is running the game on my own 6230i. Since I dont have a specific emulator for the 6300 Im not sure how can I reproduce the problem in a debuggable enviroment. Any help would be greatly appreciated. Yours Truly K [Edited by - BloodWarrior on September 18, 2007 8:21:28 AM]

[frob]

Lack of memory is not unique to any specific device.

Insufficient available memory is one of many things to check during init. You can help the memory situation by wherever possible creating a pool of objects that you reuse rather than creating new objects during runtime.

You can attempt to catch the exception and printStackTrace, but sometimes running out of memory means that you don't have the resources available to even do that. The stack trace will (usually) help you track down the allocation is causing it.

There are tools like the YourKit memory profiler that can help figure out what is eating the resources. One case I've seen is when a large object (such as a movie) was released but is still consuming tons of resources because cleanup is delayed.

Finally, as for it working on one device but not working on a later version, remember that every device is different. Each has different environments, each has a different amount of memory available to you at runtime. Each has their own unique bugs and handles resources slightly differently. Just because it is the next revision doesn't mean it is better for you.

Good luck on your error, they can be difficult to track down.

[trojanman]

Unfortunately, like with most mobile devices getting the console output is difficult or impossible.

A solution, and a reusable one at that, is to create a logging system where you can set the output of the logger (1. to the console, 2. to the screen, etc.) I have used something like this repeatedly to help debug on-device problems where you cannot do normal debugging. I have used this for slow loading, memory exceptions, and even device specific sound and library problems.

Also, there may not be a specific Nokia 6300 emulator but it is S40 3rd edition and there is an available Emulator pack for those. Check here to download the S40 3rd edition SDK and any additional feature packs.

[BloodWarrior]

Heyas Frob, trojanman

Thanks for the input.

Im not worried at all about finding the bug. The problem is I have no way to debug it. I cant find a specific sdk for the 6300 and its running fine on my Series 40 sdk and also the 6230i sdk.

Without a proper debugging tool I cant output debug info... unless I do it manualy by displaying alerts on the screen (seems like my only chance at the moment) just like Trojanman said.

Of course Im very disappointed in this. I checked the specs and both the 6300 and 6230i have a 2MB heap memory with 20k max RMS allocation. The only difference is that the 6230i has a max 512kb jar size while the 6300 allows for a 1MB jar size.

Also my game shouldnt be that memory intensive. I havent even plugged in any sound. I have java 3d games running in the 6300 (the pre installed ones) and this just seems silly. I really suspect some weird change in the phone itself.

Its ridiculous that something like this is happening.
Ill be spending some time profiling the 6230i emulator to see if i can find out how much memory its eating.

Thanks for the input!
Yours Truly
K

[frob]

Quote:

Original post by BloodWarrior I checked the specs and both the 6300 and 6230i have a 2MB heap memory with 20k max RMS allocation. The only difference is that the 6230i has a max 512kb jar size while the 6300 allows for a 1MB jar size.

OutOfMemory doesn't necessarily mean that you have consumed all your memory, nor is it always in response to an allocation from the heap.

Sometimes specific resources use their own pool and end up throwing when their little pool is exhausted. Sometimes your memory gets fragmented and a large allocation doesn't have a contiguous block. Sometimes your implementation will require an allocation from another memory source and that alternate memory source will be empty.

The mere presence of allocatable memory is not enough. One company I was at required all significant objects to be static and initialized early, and also strictly limited the creation of objects at runtime, simply because of this kind of memory problem.

Quote:

Also my game shouldnt be that memory intensive.

It doesn't have to be. For example, if you are trying to play a movie or load a file, the system could be trying to access its own internal resources and not have enough room internally. Since you keep mentioning 3D (although you have not said anything about it being the allocation that fails) maybe your vram is too fragmented for an allocation.

The point is that even apps with minimal memory requirements can suffer from memory problems, especially when you are working with internal resources, or aren't extremely careful about memory pools, or aren't careful about memory fragmentation.

Quote:

I really suspect some weird change in the phone itself.

Obviously the phones are different, but don't rule out that it may have just exposed a bug in your own code. The fact that it is your own application that fails often means that it is a bug in your own code -- even if it is very subtle. Improper resource management is your code's fault, not the fault of the hosting environment.

Quote:

Its ridiculous that something like this is happening.

The original Java mantra from Sun was "Write once, run anywhere". Developers quickly changed it to "Write once, debug everywhere". In my experience, it is nearly always that the programmer did something incorrectly or non-portably, and only rarely the fault of the device itself.

[BloodWarrior]

Heyas Frob

I agree with what you say totally.
But what I find ridiculous is that I cant debug, not that there is a problem. Because I dont have a specific sdk that reproduces the problem.
Feels like the 6300 doesnt have as much support as the 6230i has.

And yeah: I do create a lot of static objects at init (which is where something is failing). I dont use 3d at all on my game (its a simple turn based game) and there are a few pngs that need to be loaded at init. Not that many but a few.

anyways Im downloading all the latest nokia Series 40 sdks and updating all my tools.
If that doesnt help then its creating a "In phone" debug system so that I can trace the problem.

Yours Truly
K

[trojanman]

Quote:

Original post by BloodWarrior But what I find ridiculous is that I cant debug, not that there is a problem. Because I dont have a specific sdk that reproduces the problem. Feels like the 6300 doesnt have as much support as the 6230i has.

This is unfortunately not an uncommon problem. Even if you DO HAVE an emulator and SDK it doesn't always reflect 100% of what occurs on the phone. Motorola SDK's and Samsung SDK's are really indicative of this.

Quote:

Original post by BloodWarrior anyways Im downloading all the latest nokia Series 40 sdks and updating all my tools. If that doesnt help then its creating a "In phone" debug system so that I can trace the problem.

Another way of doing this without going the on device logger route is to take out all of the areas where you 'think' is the problem and find when it works. Then, slowly, start adding pieces back in to find the troublesome spot. I know this technique is tedious but it is really effective. Even though I use an on-device debugging system often I still have to resort to this, especially to find hard to see, uncommon, handset issues.

[BloodWarrior]

Ouch... fatal error!

Ok I solved the problem.
I downloaded the newest release of the sdk and fortunately i was able to reproduce the error.
Some forum search and i got the explanation for the problem (thanks shmmove.. I found your posts in the nokia forum!)

Ok so here is the problem
Im loading a huge image to break into sprites for my game menu screen. The image is 102kb so not that big BUT once loaded has to be decompressed into usable phone bitmap it transfers to width*height*colordepth. In my case its 1040*700*depth.

In the 6230i my screen depth is 16bit so the image is 1040*700*2/1024=1422kb.
In the 6300 the screen is actually 24bit which means the image is 2132kb.

While both phones actually have enough ram to handle that much memory they are still both limited to 2MB heap which means that the 6300 cant handle the huge image.

There is no way to reduce the color depth as this has to be device specific (bitmap that can be natively drawn into the phone screen).

This means that the 6300 is actually suffering from a problem handling images vs the 6230i. I hope the 6300 hardware can compensate for the bigger memory required for each image.

My problem can easilly be solved by using a smaller image, in fact probably creating a single immutable image for each menu screen will be faster since I wont be using a large chunk of the heap (hopefully the hardware will cope with the extra number of objects). This is my opinion though. It might be that once the image was loaded and the sprite created the phone JVM would handle it quite well. Alas we will never know.

The Misterious case of the 6300 failure vs the 6230i is closed.

Yours Truly
K