Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#411 Invalid instruction offset [4] in code fragment at level 1

open-accepted
5
2011-08-18
2011-08-08
Prashant Deva
No

I get this error when using proguard 4.5.1 or 4.6.
Note that the class mentioned is not even being obfuscated. It is part of a 'keep' group.

[proguard] (using '-keep').
[proguard] Unexpected error while inlining subroutines:
[proguard] Class = [com/chronon/sb/libs/netty/handler/execution/OrderedMemoryAwareThreadPoolExecutor$ChildExecutor]
[proguard] Method = [run()V]
[proguard] Exception = [java.lang.IllegalArgumentException] (Invalid instruction offset [4] in code fragment at level 1)
[proguard] java.lang.IllegalArgumentException: Invalid instruction offset [4] in code fragment at level 1

Related

Bugs: #506

Discussion

  • Eric Lafortune
    Eric Lafortune
    2011-08-09

    Can you mail me the source and the class file of com/chronon/sb/libs/netty/handler/execution/OrderedMemoryAwareThreadPoolExecutor$ChildExecutor ? I'll then look into it.

    You can avoid the problem by compiling your code with JDK 1.5 or higher, or by not specifying "-target 1.6" in your ProGuard configuration.

     
  • Eric Lafortune
    Eric Lafortune
    2011-08-09

    • assigned_to: nobody --> lafortune
     
  • Prashant Deva
    Prashant Deva
    2011-08-17

    The code is being compiled with jdk 1.6.
    what exactly does not using '-target 1.6' do?

    The code in question is of the netty 3.2.5 library.
    We just used jarjarlinks to move it in our namespace.

     
  • Prashant Deva
    Prashant Deva
    2011-08-17

    Both source and class files are now added.

     
  • Eric Lafortune
    Eric Lafortune
    2011-08-18

    • labels: --> Preverification
    • status: open --> open-accepted
     
  • Eric Lafortune
    Eric Lafortune
    2011-08-18

    It looks like this class file has been compiled with JDK 1.5, but apparently not with a compiler from an Oracle/Sun JDK. Alternatively, it's also possible that the class file has been compiled with JDK 1.4, but then jarjarlinks has changed the java bytecode version to 1.5. The bytecode still contains subroutines (jsr/ret instructions) which have been deprecated in JDK 1.5 and removed for Java 6 bytecode. With ProGuard option -target 1.6, ProGuard has to remove them, which fails in this case. I'll look into it. You can avoid the problem by not specifying this option for ProGuard, or by compiling this class with JDK 1.6 to start with.