Nokia series 40 synchronization bug (?)

[niekvs]

Hello,

I wrote a midlet that runs fine on most handsets (Motorola T720, i95cl, Siemens M50, etc), but there's a problem with running it on the Nokia 7210: for some reason, the program sometimes gets stuck completely (hangs). This happens quite randomly (but when it does, it always happens when pressing a button), so it's hard to track down, but i found out it has something to do with synchronized methods and the event-dispatching thread.

First, let me ask: is there a regularly updated "known bugs" list available for the Nokia JVM implementations? If not: why not? It would be one of the most useful things on this site, in my opinion.

Ok, now i'll continue with the problem: the problem seems to occur when the event dispatching thread is busy drawing something on the screen, and *while* it's doing that, i press a button (catching it with keyPressed() in FullCanvas) and call a synchronized method. This makes the JVM hang, deadlock. I don't think this is caused by my program, but is a bug in the JVM. I can reasonably consistently reproduce it at some point in my program: it's drawing something on the screen, and i press one of the soft buttons which leads me to a menu (a List). Because i implemented hideNotify(), this method is called, and hideNotify() calls another method that is synchronized. It doesn't seem to matter what object it's synchronized on. Just that it's synchronized. When i remove the synchronized keyword from the method, the problem doesn't occur. It seems to have something to do with the event-dispatching thread, because it only happens while that thread is busy (drawing something, in this case). So the event-dispatching thread is doing something, and at the same time a key event calls (directly, or indirectly through hideNotify()) a synchronized method. I haven't taken it to the point of creating one easy to use example class to demonstrate this, but if Nokia is interested, i will share the code with you. By the way: the paint method isn't synchronized in any way, but in my case the synchronized method does draw something, but only to an offscreen image. I'll check later to see if it also deadlocks when this method is not drawing anything.

I hope you can fix this bug, as well as produce a "known-bugs" list, which i think many developers would find very useful.

Regards,
-- Niek

[mrwolf]

Hi,

i am experiencing the same problem with the keyPressed(int) method. Actually synchronization should not even be necesarry, since the documentation states that keyPressed is called serially (which, if i understood the docs correctly, means that a second keyPressed event will only be thrown after the first event has been handled).
The problem pretty much pins down to the following lines of code:

public void goLevel2(){ //gets called by keyPressed, if the level has been cleared
synchronized(this){ //GameMIDlet enters monitor, further calls will block
if(level2!=null) return; //level2 will be null for the first keyPress and only for the first keyPress, see below
level1=null;
level2=new Level2(this); //need backreference to MIDlet
Display.getDisplay(this).setCurrent(level2); //Note: Level2 extends FullCanvas and implements Runnable
level2.go(); //some ini stuff and starts Thread
}
}

As i see it, there should be no possibility of this method passing past the "return" statement twice via repeated keyPresses. However pressing the "nextLevel" key will result in a deadlock. Without synchronisation the method will be called several times, resulting in the invocation if several Threads and, depending on how often the key was pressed, a crash. This code fragment seem trivial enough (if i made a mistake somewhere, please tell me) to consider the VM implementation buggy.

Greetz
Syren

[huang_miles]

Yes, I've encounter same problem as previous developers.
In my program, I use a TimerTask driven thread to process offscreen buffer's drawing task and the Canvas's paint method just draw the offscreen buffer with synchronization.
When the keyPressed method is called while the screen is updating ( by key press ), the program fall into deadlock.
The program runs successfully on Sun WTK & various Moto cell phones.
I consider this is a serious bug ( at least something must be take care especially for Nokia 40 series developing ).
Can Nokia stuff give some comments or suggestion on this problem?

[mrwolf]

Well,

hmpf, i guess i can can tell you guys what i found out. After about 1-2 weeks of trying.
It seems best to try to use a good ol polling technique. Or, to be more precise, DONT call methods from keyPressed(...) but instead set a (static) global variable, which you check elsewhere.
So instead of inserting a call doSometining() in keypressed(...) rather set a viable and check it in a seperate Thread.
Yeah, it sure helps.

Greets,
Syren Baran aka Mr.Wolf