×

Discussion Board

Results 1 to 11 of 11
  1. #1
    Registered User
    Join Date
    May 2007
    Posts
    91

    Thumbs down Error verifying method start App()/commandAction()

    Hello,
    We often come across
    Error verifying method {midlet.name} start App()V
    Error verifying method {midlet.name} commandAction(Ljavax/microedition/lcdui/Command;Ljavax/microedition/lcdui/DisplayableV
    above Runtime Error. Could we share our experience on it.



    Amit

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

    Re: Error verifying method start App()/commandAction()

    You come across these errors are runtime, or when building?

    If at runtime, on what devices? Do you get this when using obfuscated code, or unobfuscated?

    Graham.

  3. #3
    Registered User
    Join Date
    May 2007
    Posts
    91

    Post Re: Error verifying method start App()/commandAction()

    Hello Graham,

    I come across this thing
    Error verifying method {midlet.name} start App()V
    when I tried to launch my application on emulator(WTK25-Beta2 and WTK22) and on device(ZTE T100) it just shows a white screen for a while (1 sec) and return back to game list menu whereas on KEmulator it is working fine. I have also tried it with unobfuscation.



    Amit
    Last edited by amit_yadav; 2010-02-03 at 09:39. Reason: I don't want to reveal my company public server link

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

    Re: Error verifying method start App()/commandAction()

    Is this the same issue? It shows the white screen, and you get the "Error verifying..."?

    I don't use KEmulator... if I remember right, it's an ME-on-SE layer, useless for diagnosing this kind of problem.

    If you get this verifying error in unobfuscated builds, the main possibilities are:

    1. The classes are not preverified. However, the usual message here is "bad or missing stack map".

    2. The classes have been subjected to some form of byte-code modification after preverification. Preverification needs to be the last step.

    3. You're using CLDC-1.1 code on a CLDC-1.0 device. That won't be the case if you see the problem on the WTK.

    I'll look at the JARs later, when I'm back at my PC.

    Graham.

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

    Re: Error verifying method start App()/commandAction()

    I looked in the unob'd JAR... the classes don't appear to be preverified.

    Graham.

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

    Re: Error verifying method start App()/commandAction()

    Preverifying doesn't help. They still fail.

    The classes appear to contain invalid byte-code sequences. The verifier is quite correct in rejecting them. I don't believe these classes have been generated directly by the Sun Java compiler. Coral.Util.crlUtil.garbageWait(), for example (which is a hideous method that shouldn't even exist!) contains an invalid sequence. It appears to contain a stray byte-code operation that, while unreachable, would be impossible to execute (it would generate a stack underflow). There are other examples. I believe these stray opcodes may be confusing the verifier. How they have been injected into the byte-code, I have no idea. My guess is that you have some strange tool in your build process, some kind of "optimizer", perhaps?

    Graham.

  7. #7
    Registered User
    Join Date
    May 2007
    Posts
    91

    Thumbs up Re: Error verifying method start App()/commandAction()

    Hello Graham,

    This time really all things have been moved to over my head, like something even I couldn't imagine but I would like to know about it which might be helpful to diagnose my problem.

    I would like to know:
    (1) How you come to know that the classes are not preverified
    (2) How I'll preverify it manually, mean to say how I can excute preverify.exe with arguments
    (3)Finally how you can say that Coral.Util.crlUtil.garbageWait() has byte code sequence problem, I have tried to comment that code but still the problem is there.
    And last but not the least thanku very much for a wonderfull reply!


    Amit.

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

    Re: Error verifying method start App()/commandAction()

    You can examine the contents of a .class file using the "javap" utility in the JDK. For example:

    Code:
    javap -classpath eidos_f_ztet100_english_california_games_x_v0_0_1.jar Coral.Util.crlUtil
    This will just give you a list of public members. Different options will give you different information. Use -v ("verbose") to get a complete contents of the .class file. (-v will generate a lot of output, including complete disassembly of all the byte-code.)

    The classes (at least, the ones I checked) contained no StackMap chunks. StackMaps are added to some methods by the preverifier, which is why .class files get larger when preverified.

    Sorry, I misread the code... what I took to be an "extra" byte code is actually part of the exception handler, which it why it looks unreachable. I didn't read the exception table for the method. The byte code is, indeed, valid.

    If you run javap for that class (with the -v option), you'll see:

    Code:
    public static final void garbageWait();
      Code:
       Stack=2, Locals=1, Args_size=0
       0:   invokestatic    #2; //Method java/lang/System.gc:()V
       3:   invokestatic    #2; //Method java/lang/System.gc:()V
       6:   ldc2_w  #3; //long 500l
       9:   invokestatic    #5; //Method java/lang/Thread.sleep:(J)V
       12:  invokestatic    #6; //Method java/lang/Thread.yield:()V
       15:  goto    19
       18:  astore_0
       19:  return
      Exception table:
       from   to  target type
         0    15    18   Class java/lang/Exception
    Which, I was mistaken, is actually fine. However, if I preverify the class, this changes:

    Code:
    public static final void garbageWait();
      Code:
       Stack=2, Locals=1, Args_size=0
       0:   invokestatic    #9; //Method java/lang/System.gc:()V
       3:   invokestatic    #9; //Method java/lang/System.gc:()V
       6:   ldc2_w  #6; //long 500l
       9:   invokestatic    #10; //Method java/lang/Thread.sleep:(J)V
       12:  invokestatic    #11; //Method java/lang/Thread.yield:()V
       15:  goto    19
       18:  astore_0
       19:  return
      Exception table:
       from   to  target type
         0    15    18   Class java/lang/Exception
    
      StackMap: number_of_entries = 2
       18:
        locals = []
        stack = [ class java/lang/Exception ]
       19:
        locals = []
        stack = []
    Note the addition of the StackMap chunk to this method. This certainly explains why the cods fails on the WTK emulator and the handset, but works on KEmulator. KEmulator is actually running on a standard J2SE JVM, not a J2ME, CLDC KVM. CLDC VMs require the StackMaps, whereas standard JVMs do not.

    (What are StackMaps for? Contrary to popular opinion, the preverifier does not verify the code. All Java VMs (SE and ME) verify the .class files when they are loaded, to ensure that they are valid, executable code. To do this, the VM scans the byte code, working out what will be on the stack at every point in the program. It then checks for each instruction that there are enough units of data on the stack, and they are the right types. For example, an "iadd" (integer addition) instruction requires two units on the stack, both of type "int". If the VM cannot prove that the data on the stack will be correct, it will reject the class. This list of what it on the stack at each point is called a "stack map". Constructing stack maps is time consuming and memory-hungry, and therefore problematic on mobile devices. To make verification faster, the preverifier is used to add a stack map into the .class files. To avoid bloating the .class files too much, these maps are limited only to certain points in the code, typically to those byte codes that can be reached from more than one preceeding byte code (such as the target of a "jump"), because these are the points where the stack map is most complicated to construct. Some methods, therefore, will not have a stack map. The verifier in the device's VM then uses this chunk of data to help it work faster. If it's missing, you might see messages like "verify error" or "bad or missing stack map". As of Java 6, Standard Edition Java now also uses stack maps to improve start-up times - however, they are optional (so that the JVM can still load and verify classes without stack maps) and the stack maps are not in the same format as CLDC stack maps.)

    Why I still had an error after preverifying, I don't know. This would require more investigation.

    Your build process should be preverifying for you. Possibly there was some diagnostic output from the build which you have missed, or which was not reported to the console for some reason.

    Hope this helps,
    Graham.

  9. #9
    Registered User
    Join Date
    May 2007
    Posts
    91

    Thumbs up Re: Error verifying method start App()/commandAction()

    Hello Graham,
    This time really I come to know a pretty good things which had been always be a part of mistery for most of the developers and known to few of them. I'll try to find out what the exact reason behind this error but for this first I have to preverify my classes here only for that I would like to know how I'll preverify my class files using preverify.exe utility. Please explain me preverify.exe usage. Once again thanks a lot to you.


    Amit.

  10. #10
    Registered User
    Join Date
    May 2007
    Posts
    91

    Thumbs up Re: Error verifying method start App()/commandAction()

    Hello Graham,
    Good News! I have been preverify the JAR(classes) using Antenna script

    PHP Code:
            <path id="boot.classpath">
                <
    filelist dir="../lib/Midp2/Nokia_s60_MIDP20/" files="classes.zip"/>            
            </
    path>    
            
           <
    wtkpreverify 
                jarfile
    =".\builds\ztet100\eidos_f_ztet100_english_california_games_x_v0_0_1.jar" 
            
    cldc ="false"
                
    bootclasspathref="boot.classpath"/> 
    Instead of by using WTK preverify.exe which has been used earlier in script.
    PHP Code:
            <exec executable="${wtk.home}/bin/preverify">
             <
    arg line="-classpath ${wtk.midpapi}"/>
             <
    arg line="-d ${obfuscated.classes.dir}"/>
             <
    arg line="${dir.build}/preverified"/>
            </
    exec
    Its really because of your proper guidance on this problem. Otherwise it was seems to be unimaginable to fix it. Really you are a genious even I should say that I have no words to addressed you!!!


    Amit.
    Last edited by amit_yadav; 2011-01-17 at 15:21. Reason: I don't want to reveal my company public server link

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

    Re: Error verifying method start App()/commandAction()

    That's good - well done! Something must have failed when I tried to preverify it. I did have some problems, because one of the class references a Mascot 3D API class, for which I had no library JAR. Perhaps that screwed me up.

    Well... your build script should have had this already! If not, no one else can build this either. It should not have been delivered to you like this - some procedure has let you down.

    Graham.

Similar Threads

  1. Unable to start the Platform_SDKs_for_Symbian_OS
    By nagkumar in forum Mobile Java Tools & SDKs
    Replies: 2
    Last Post: 2008-09-05, 18:25
  2. What is happening in InputStream.Skip method?
    By orsteglasy in forum Mobile Java Networking & Messaging & Security
    Replies: 0
    Last Post: 2007-03-02, 19:34
  3. Is switching to another Canvas inside a paint() method OK?
    By falconpl in forum Mobile Java General
    Replies: 2
    Last Post: 2006-05-06, 00:15
  4. Determine start method
    By johnbutler in forum Mobile Java General
    Replies: 0
    Last Post: 2005-11-29, 13:24
  5. start a thread from another thread
    By white_dragon in forum Symbian
    Replies: 1
    Last Post: 2005-05-23, 13:44

Posting Permissions

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