×

Discussion Board

Results 1 to 12 of 12
  1. #1
    Regular Contributor
    Join Date
    May 2004
    Posts
    147

    Exclamation 5800 JVM bug related to array allocation?

    I narrowed down a program problem to a class scope array allocation (I assume it compiles into the constructor) that was just null (example below). Moving the allocation from class scope to the function I was first using it in appeased the phone.

    The original code works fine after restarting the phone or on emulators. But it can start happening again after a while, I'm not sure of the pattern, maybe after a few runs or reinstallation.

    This is on 5800 v31 with J9 2.3 2008/10/15.

    Is this a known bug?

    Any idea what might be the trigger that makes the VM trip over itself? Class structure/hierarchy/size? VM leftovers from previous runs? Something else?

    Example for "bad":

    Code:
    class B extends A {
      Image iarray[] = new Image[3];
      void func1() {
        // iarray is null here
      }
    }
    Example for "good":

    Code:
    class B extends A {
      Image iarray[];
      void func1() {
        iarray = new Image[3];
        // iarray is not null
      }
    }

  2. #2
    Super Contributor
    Join Date
    Nov 2009
    Location
    Minnesota, USA
    Posts
    3,209

    Re: 5800 JVM bug related to array allocation?

    If func1 is being called out of the constructor (explicitly or implicitly -- due to another initialization) then this is probably possible.

  3. #3
    Regular Contributor
    Join Date
    May 2004
    Posts
    147

    Re: 5800 JVM bug related to array allocation?

    Quote Originally Posted by danhicksbyron View Post
    If func1 is being called out of the constructor (explicitly or implicitly -- due to another initialization) then this is probably possible.
    Even if it were called from the constructor it should work. But regardless, it isn't in this case, and it works correctly after a device restart.

    There is nothing invalid in doing:

    Code:
    class B extends A {
    
      Image iarray[] = new Image[3];
    
      B() {
        // iarray shouldn't be null here
        func1();
      }
    
      void func1() {
        // iarray shouldn't be null here either
      }
    
    }

  4. #4
    Super Contributor
    Join Date
    Nov 2009
    Location
    Minnesota, USA
    Posts
    3,209

    Re: 5800 JVM bug related to array allocation?

    An active field initialization must be accomplished by adding code to the object constructor. Normally this would be added at the beginning, but if you have other active inits there are no guarantees as to their order.

  5. #5
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: 5800 JVM bug related to array allocation?

    Can you post a complete (minimal) MIDlet that reproduces the issue?

    Also, the full firmware version (key in *#0000# to see this) of the offending handsets.

    Can you reproduce this on other S60 5th Ed devices? Do you have S60 5th Ed devices on which the problem does not occur?

    What compiler are you using?

    Graham.

  6. #6
    Regular Contributor
    Join Date
    May 2004
    Posts
    147

    Re: 5800 JVM bug related to array allocation?

    Quote Originally Posted by danhicksbyron View Post
    An active field initialization must be accomplished by adding code to the object constructor. Normally this would be added at the beginning, but if you have other active inits there are no guarantees as to their order.
    But this isn't a problem of cross-referencing in multiple instance initializers. The function that uses it is called after the constructor in any case.

    Quote Originally Posted by grahamhughes View Post
    Can you post a complete (minimal) MIDlet that reproduces the issue?
    I haven't dug deep. I will try later to create something minimal, but I suspect the problem may not appear so readily.

    The exact firmware is 31.0.008.C01.01 on RM-356. Haven't tried other devices (it doesn't happen in all cases with the exact same build, so work is needed to find the trigger). Compiled with 1.4.2.

  7. #7
    Super Contributor
    Join Date
    Nov 2009
    Location
    Minnesota, USA
    Posts
    3,209

    Re: 5800 JVM bug related to array allocation?

    Well, the example you're posting is too blazingly simple to fail, even if there was a fairly severe bug in the JVM. If, by some odd chance, there really is a JVM bug, it's due to some complexity far beyond what you've presented. It's much more likely to be a bug in your code, however.

    Understand that that initializer you show ends up being added to the constructor by javac. So there would be no way to get through the constructor for your object without executing the initializer.

    Here is a simple class with initializations:

    Code:
    public class TestInit {
    	String[] someArray = new String[3];
    	int x = 10;
    	public TestInit() {
    		someArray[1] = "How now brown cow";
    		x = 20;
    	}
    }
    And here are the bytecodes for the constructor method:

    Code:
    Method #0:
        Access flags = 0x0001  Name: <init>()V
    
        method_info attribute #0 (Code) :
        max_stack = 3, max_locals = 1, code_length = 33, starting offset = 282
    
             0: 2a              aload_0       
             1: b7 00 01        invokespecial java/lang/Object.<init>()V
             4: 2a              aload_0       
             5: 06              iconst_3      
             6: bd 00 02        anewarray     java/lang/String
             9: b5 00 03        putfield      TestInit.someArray ([Ljava/lang/String;)
            12: 2a              aload_0       
            13: 10 0a           bipush        10
            15: b5 00 04        putfield      TestInit.x (I)
            18: 2a              aload_0       
            19: b4 00 03        getfield      TestInit.someArray ([Ljava/lang/String;)
            22: 04              iconst_1      
            23: 12 05           ldc           5 String "How now brown cow"
            25: 53              aastore       
            26: 2a              aload_0       
            27: 10 14           bipush        20
            29: b5 00 04        putfield      TestInit.x (I)
            32: b1              return
    As you can see, the initializations are performed in the <init> method (which is the constructor).

  8. #8
    Regular Contributor
    Join Date
    May 2004
    Posts
    147

    Re: 5800 JVM bug related to array allocation?

    Indeed, it's more complex. I dug more and it seems failure depends on the effect of calling a method in a half-constructued object. Whether this call happens depends on the timing of certain internal LCDUI aspects, which is where I think the bug is. I will investigate it more later, but regardless, there's probably a bug in the native API integration (and not the VM) as it does work in certain cases, and doesn't in others, with the only difference being factors external to the app.

    1. It always works after a device restart: Device restart -> run app -> C() constructor called (see below).
    2. It never, or rarely, works when run after reinstallation: Device restart -> reinstall app -> run app -> C() constructor not called.

    A more complete example:

    Code:
    class A extends MIDlet {
    
      startApp() {
        c = new C();
        Display.getDisplay(this).setCurrent(c); // if here, always good
      }
    
    }
    Code:
    class B extends GameCanvas {
    
      B() {
        Display.getDisplay(midlet).setCurrent(this); // if here, sometimes bad
      }
    
      abstract func1();
    
      showNotify() {
        func1();
      }
    
    }
    Code:
    class C extends B {
    
      C() {
        // stuff here might not be executed
      }
    
      func1() {
      }
    
    }
    It probably works correctly when showNotify() is called serialized after the constructor returns rather than immediately.

  9. #9
    Super Contributor
    Join Date
    Nov 2009
    Location
    Minnesota, USA
    Posts
    3,209

    Re: 5800 JVM bug related to array allocation?

    If C extends B then by default B's constructor runs first. Any reference to "this" in B's constructor will be referencing an incompletely initialized C. Nothing at all mysterious (or buggy) about this.

  10. #10
    Regular Contributor
    Join Date
    May 2004
    Posts
    147

    Re: 5800 JVM bug related to array allocation?

    Quote Originally Posted by danhicksbyron View Post
    If C extends B then by default B's constructor runs first. Any reference to "this" in B's constructor will be referencing an incompletely initialized C. Nothing at all mysterious (or buggy) about this.
    I didn't say there was a bug in this. The bug is the different behavior between 1 and 2 above.

  11. #11
    Super Contributor
    Join Date
    Nov 2009
    Location
    Minnesota, USA
    Posts
    3,209

    Re: 5800 JVM bug related to array allocation?

    I'm guessing that your code takes different paths depending. Either you've initialized some file or some such, or there are timing dependencies with regard to some asynchronous activity in your app.

  12. #12
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: 5800 JVM bug related to array allocation?

    Remember that setCurrent() may have no immediate effect. It works by posting events to the event queue. Therefore, if you call it while handling an event, it will have no effect until you return from the event-handler method, allowing more events to be processed. On the other hand, if it is called from another thread, the events it creates will be processed in parallel, creating timing differences.

    This is no VM bug, just a thread synchronization issue.

    Graham.

Similar Threads

  1. Replies: 4
    Last Post: 2009-11-03, 11:36
  2. How to do dynamic allocation of pointer array?
    By SymbianTH in forum Open C/C++
    Replies: 1
    Last Post: 2009-11-02, 15:33
  3. heap allocation of JVM
    By metebalci in forum Mobile Java General
    Replies: 0
    Last Post: 2005-06-10, 09:34
  4. Memory allocation in JVM
    By andypro in forum Mobile Java General
    Replies: 0
    Last Post: 2004-09-27, 08:08
  5. soft key bug in 3410 JVM
    By jeep_ in forum Mobile Java General
    Replies: 1
    Last Post: 2002-07-03, 11:25

Posting Permissions

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