JDK-6702394 : [C1] IncompatibleClassChangeError while running proguard
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6u10
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86
  • Submitted: 2008-05-14
  • Updated: 2010-04-04
  • Resolved: 2008-05-14
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.6.0_10-beta"
Java(TM) SE Runtime Environment (build 1.6.0_10-beta-b22)
Java HotSpot(TM) Client VM (build 11.0-b11, mixed mode, sharing)

FULL OS VERSION :
Linux localhost.localdomain 2.6.20.1 #3 SMP Sun Mar 25 22:45:33 CEST 2007 i686 i686 i386 GNU/Linux


A DESCRIPTION OF THE PROBLEM :
When running proguard-4.2 to process some of my jars I constantly get a java.lang.IncompatibleClassChangeError and my build-process aborts.

The strange thing is this only happens when running with -client, when running with -server everything works fine.
Also running proguard with java-5 everything works as expected.

However I don't know wether this error only happens with my jar-files, so if you whish I could send you a small package containing a jar-file and the approproate configuration-file to trigger the problem. Don't hestitate to mail me ;)
By the way there were other reports about this problem at the proguard-forums already.


THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: No

THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: No

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.) Run proguard-4.2 on JDK6u10 and let it shrink some jar
2.) proguard will abort with the exception

EXPECTED VERSUS ACTUAL BEHAVIOR :
no errors
ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread "main" java.lang.IncompatibleClassChangeError
        at proguard.classfile.attribute.LineNumberTableAttribute.accept(LineNumberTableAttribute.java:70)
        at proguard.classfile.attribute.CodeAttribute.attributesAccept(CodeAttribute.java:173)
        at proguard.classfile.util.ClassReferenceInitializer.visitCodeAttribute(ClassReferenceInitializer.java:277)
        at proguard.classfile.attribute.CodeAttribute.accept(CodeAttribute.java:75)
        at proguard.classfile.ProgramMethod.attributesAccept(ProgramMethod.java:62)
        at proguard.classfile.util.ClassReferenceInitializer.visitProgramMethod(ClassReferenceInitializer.java:128)
        at proguard.classfile.ProgramMethod.accept(ProgramMethod.java:54)
        at proguard.classfile.ProgramClass.methodsAccept(ProgramClass.java:388)
        at proguard.classfile.util.ClassReferenceInitializer.visitProgramClass(ClassReferenceInitializer.java:95)
        at proguard.classfile.ProgramClass.accept(ProgramClass.java:281)
        at proguard.classfile.ClassPool.classesAccept(ClassPool.java:114)
        at proguard.Initializer.execute(Initializer.java:97)
        at proguard.ProGuard.initialize(ProGuard.java:210)
        at proguard.ProGuard.execute(ProGuard.java:85)
        at proguard.ProGuard.main(ProGuard.java:499)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
I can send a self-contained test-case by email.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
build with JDK5

Release Regression From : 6u6
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.

Comments
EVALUATION I'm sure this is a duplicate of 6610906. The fix for this should be in the next release of 6u10. Look for the hotspot version string to be 11.0-b12. It's already in their engineering workspace and just hasn't been pushed out. The bug should also reproduce with JDK7 build b20 through b25 and the fix is in b26 if you want to confirm it.
14-05-2008