[appeal]

I have encountered a serious bug in the Nokia 6600 JVM, at least on my phone (firmware 3.42.1), that leaves the phone in a non-responsive state. To recover you need to take out the battery to turn the phone off and then on again.

I have not been able to find the bug described in the latest "Known Issues In The Nokia 6600 v1.3" pdf-file (http://www.forum.nokia.com/main/0,65...ml&fileID=5001).

I would like if anyone could try this out on their phone to see if it is just my phone or just this firmware. Just try a simple line like the following:

Image.createRGBImage(new int[64*64], 64, 64, true);


_____Full description:_____

(all references refer to the methods working on immutable semi-transparent images/data)

__Image.createRGBImage()__
When using the MIDP 2.0 api for creating an immutable, semi-transparent image from RGB data, if the pixel array is larger than about 4096, the phone will hang.


__Image.getRGB()__
When using the MIDP 2.0 api for grabing RGB data from an immutable, semi-transparent image, if the pixel size of the source image is larger than about 4096, the phone will hang.

__Graphics.drawRGB__
The bug is not seen here, even if using large semi-transparent data.

My guess is that what we see here is simply a buffer overflow in the JVM implementation.

Can anyone confirm this on their devices. On other Symbian 7.0 phones?

/appeal


_____Full example code:_____

// Create array with more data than needed
int[] data = new int[200*200];
// Create 100x100 non-alpha image. OK
Image.createRGBImage(data, 100, 100, false);
// Create 64x63 (4032 pixels) alpha image. OK
Image.createRGBImage(data, 64, 63, true);
// Create 64x64 (4096 pixels) alpha image. Phone hangs!
Image.createRGBImage(data, 64, 64, true);


// Create array with more data than needed
int[] rgb = new int[64*64];
Image image1 = Image.createImage("/64x63_alpha.png");
// Grabs 64x63 (4032 pixels) rgb from alpha image. OK
image2.getRGB(rgb, 0, 64, 0, 0, 64, 63);

Image image2 = Image.createImage("/64x64_alpha.png");
// Grabs 64x64 (4096 pixels) rgb from alpha image. Phone hangs!
image2.getRGB(rgb, 0, 64, 0, 0, 64, 64);

[morousseau]

Hello

Have you tried the DirectGraphics.getPixels function? even though Nokia says that its better to use MIDP2 functions on this phone, i got my app working by using Nokia API function instead.

DirectGraphics.getPixels(arrayData, 0, iW, 0, 0, iW, iH, DirectGraphics.TYPE_USHORT_4444_ARGB);

Also, i use a preprocessor base on Wave:

http://spirit.sourceforge.net/index....1_0/index.html

With the pp, i can do something like:

#ifdef Nokia6600
dg.getPixels....
#else
g.getPixels(....)
#endif

Its quite useful

-Oli

[ianjames]

Hi,

I have exactly the same problem with createRGBImage on my 6600. I have firmware v3.42 which seems to be the first released firmware for this phone.

Does anyone know if these bugs are present in later firmware revisions or on the similar 7610 phone?

Thanks

Ian

[apetrik]

Could someone tell me what phones also crushes with RGB operations except Nokia 6600? Maybe some of MIDP2 Nokia Series 60 also crush?
Thank you...

[zubs20]

Im getting the same problem on the Nokia 7610. The phone hangs when executing the Image.createRGBImage(...); I am very fusrated with this problem. Can anyone please provide help here.

[svo]

This seems to be true for 3230 as well. I'm developing a little game and it works fine everywhere except 3230 (the only S60 phone I could get a hold of). On 3230 it results in a complete death of phone, battery needs to be removed. I searched a lot on this forum, until I found this and several other threads addressing the same issue.

Nokia, why none of these threads get any attention from you? At least an acknowledgement that yes, we indeed don't have unit tests for Series 60 Java, would do fine. We will know then that this problem is real and addressed. As of now, it is a waste of time for me & other developers and a huge hit for your karma that makes it dangerously close to Integer.MIN_VALUE. Wake up, please, we kind of need you sometimes.

[weibsvolk]

I'm having the same problem and could not find any documentation for a workaround..