Menu

#17 False detection of exception handler bug

open
decompiler (49)
5
2001-11-23
2001-11-23
Anonymous
No

The decompiler abusively complains about an invalid
exception handler table with the following exception
trace:

jode.AssertError: ExceptionHandler order failed: not
24 < 27 <= 24
at
jode.flow.TransformExceptionHandlers.checkTryCatchOrder
(TransformExceptionHandlers.java:904)
at jode.flow.TransformExceptionHandlers.analyze
(TransformExceptionHandlers.java:928)
at jode.decompiler.MethodAnalyzer.analyzeCode
(MethodAnalyzer.java:577)
at jode.decompiler.MethodAnalyzer.analyze
(MethodAnalyzer.java:652)
at jode.decompiler.ClassAnalyzer.analyze
(ClassAnalyzer.java:359)
at jode.decompiler.ClassAnalyzer.dumpJavaFile
(ClassAnalyzer.java:624)
at jode.decompiler.Decompiler.decompile
(Decompiler.java:192)

The same class is correctly decompiler with JavaP.
Following is an extract corresponding to the exception
table output by javap:

Method void testCompleted(boolean)
0 aload_0
1 iload_1
2 putfield #14 <Field boolean success_>
5 aload_0
6 getfield #16 <Field java.lang.Object
testCompletionLock_>
9 astore_2
10 aload_2
11 monitorenter
12 aload_0
13 getfield #16 <Field java.lang.Object
testCompletionLock_>
16 invokevirtual #30 <Method void notify()>
19 aload_2
20 monitorexit
21 goto 29
24 astore_3
25 aload_2
26 monitorexit
27 aload_3
28 athrow
29 return
Exception table:
from to target type
12 21 24 any
24 27 24 any

Line numbers for method void testCompleted(boolean)
line 191: 0
line 192: 5
line 193: 12
line 194: 19
line 195: 29

Following is the corresponding original source:
public void testCompleted(boolean withSuccess) {
success_ = withSuccess;
synchronized(testCompletionLock_) {
testCompletionLock_.notify();
}
}

The source was compiled with the JDK 1.4beta3. I don't
quite understand why there is an exception handler in
this method since the source code does not have a try
block.

I can provide binary and source class if this can help
debugging the problem.

BTW, JODE is great, Thanks for this!

Regards,

Guillaume.
gberche@acm.org

Discussion

  • Jochen Hoenicke

    Jochen Hoenicke - 2001-11-23

    Logged In: YES
    user_id=18252

    The VM spec lied again; section 4.9.5 said:

    Java virtual machine code produced by Sun's compiler for
    the Java programming language always generates exception
    handlers such that: [...] The handler for an exception
    will never be inside the code that is being protected.

    This is the rule that I checked and that failed. The code
    it produced is clear: The virtual machine locks and
    unlocks monitors with monitorenter and monitorexit, so it
    need to call monitorexit when an exception occurs. They
    seemed to be a bit paranoid and put a second handler
    around the monitorexit instruction.

    I have to think how to handle this cleanly. The quick'n
    dirty way is to simply remove all exception handlers that
    violate this rule.

     
  • Jochen Hoenicke

    Jochen Hoenicke - 2001-11-23
    • assigned_to: nobody --> hoenicke
     
  • Dirk Möbius

    Dirk Möbius - 2002-02-26

    Logged In: YES
    user_id=9521

    I don't know whether this is the same error. During
    decompilation of com.sun.tools.javac.v8.Main, I get:

    $ java -cp "java-getopt-1.0.8.jar;jode.jar"
    net.sf.jode.decompiler.Main --
    classpath "D:\Programme\Java\j2sdk1.4.0
    \jre\lib\rt.jar,D:\Programme\Java\j2sdk1.4.0\lib\tools.jar"
    com.sun.tools.javac.v8.Main

    java.lang.InternalError: ExceptionHandler order failed: not
    22 < 22 <= 22
    at
    net.sf.jode.flow.TransformExceptionHandlers.checkTryCatchOrd
    er(Unknown Source)
    at
    net.sf.jode.flow.TransformExceptionHandlers.analyze(Unknown
    Source)
    at net.sf.jode.decompiler.MethodAnalyzer.analyzeCode
    (Unknown Source)
    at net.sf.jode.decompiler.MethodAnalyzer.analyze
    (Unknown Source)
    at net.sf.jode.decompiler.ClassAnalyzer.analyze
    (Unknown Source)
    at net.sf.jode.decompiler.ClassAnalyzer.dumpJavaFile
    (Unknown Source)
    at net.sf.jode.decompiler.ClassAnalyzer.dumpJavaFile
    (Unknown Source)
    at net.sf.jode.decompiler.Main.decompileClass
    (Unknown Source)
    at net.sf.jode.decompiler.Main.decompile(Unknown
    Source)
    at net.sf.jode.decompiler.Main.main(Unknown Source)

    Shouldn't 22 < 22 <= 22 be allowed, regardless of the VM
    spec?!?

    Dirk.

     
  • Jochen Hoenicke

    Jochen Hoenicke - 2002-02-26

    Logged In: YES
    user_id=18252

    Regarding Dirk's comment from today: This is exactly the
    same error just in the jode-1.90-CVS variant.

    BTW the error message should be "not 22 <= 22 < 22", as
    this is what is checked (I changed the meaning of "try
    block end" to be inclusive not exclusive).

     

Log in to post a comment.