Community
Participate
Working Groups
Created attachment 275089 [details] eclipse-project When debugging a project with a (specific) Java 1.4 jar on the class path, I get the following error: Exception in thread "main" java.lang.ClassFormatError: Invalid length 65494 in LocalVariableTable in class file kodo/kernel/KodoBroker at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:763) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) at java.net.URLClassLoader.access$100(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:368) at java.net.URLClassLoader$1.run(URLClassLoader.java:362) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:361) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at test.Main.main(Main.java:7) When running the project, there is no error. Eclipse Oxygen also no error debugging the same project. Version: Photon Release (4.8.0) Build id: 20180619-1200 I've attached an Eclipse project with the jar which gives the problem. The project uses Java 8, running JDK 1.8.0_181 (64 bit).
Please disable "Java -> Debug -> Use advanced source lookup" and check. I wonder why don't we have a warning for that? Or do we?
Thanks for the quick response, that works. As you mention, a more user-friendly warning would be nice, or even automatically exclude classes with Java 1.4 byte code or lower from this 'advanced source lookup'. If it is really the Java 1.4 byte code that is the problem, I suppose the option description would be better as: (Java 1.5+ byte code required on the entire class path)
@Igor, Can we do something for this?
From what I can tell, kodo/kernel/KodoBroker class is invalid (see below) and ASM does not handle this too gracefully. There is an old ASM bugreport [1] where ASM developers decline to support malformed class files. I see several ways to deal with this (in my order of preference): * we document this limitation somewhere and advice users to turn off advanced source lookup if they have to debug malformed classes. * we change the agent or patch ASM to detect this specific problem so we can skip instrumentation of problematic classes. * we provide user-configurable list of class files that must not be instrumented. WDYT? [1] https://gitlab.ow2.org/asm/asm/issues/310932 kodo/kernel/KodoBroker analysis ------------------------------- Several methods of this class have invalid LocalVariableTable tables. For example #persist(Object, OpCallbacks) has the following LocalVariableTable entry Start Length Slot Name Signature 43 7 0 this Lkodo/kernel/KodoBroker; According to Java Virtual Machine Specification section 4.7.13 [2] "The value of start_pc + length must either be a valid index into the code array of this Code attribute and be the index of the opcode of an instruction, or it must be the first index beyond the end of that code array." For #persist(Object, OpCallbacks) method and several others in the class, however, start_pc + length is not a valid instruction index. [2] https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.7.13
(In reply to Igor Fedorenko from comment #4) > From what I can tell, kodo/kernel/KodoBroker class is invalid (see below) > and ASM does not handle this too gracefully. There is an old ASM bugreport > [1] where ASM developers decline to support malformed class files. > > I see several ways to deal with this (in my order of preference): > > * we document this limitation somewhere and advice users to turn off > advanced source lookup if they have to debug malformed classes. This is the easiest. > * we change the agent or patch ASM to detect this specific problem so we can > skip instrumentation of problematic classes. If this is possible - I will vote for this. > * we provide user-configurable list of class files that must not be > instrumented. This can be a add on solution. > > WDYT?
(In reply to Sarika Sinha from comment #5) > > > > * we change the agent or patch ASM to detect this specific problem so we can > > skip instrumentation of problematic classes. > If this is possible - I will vote for this. The check is not "free", it adds complexity to the agent, which will make it harder to maintain and maybe slower at runtime. I recommend we wait and see how widespread the problem is before we implement the check.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
