Community
Participate
Working Groups
This error doesn't come if you compile with older versions of eclipse... The testcode: public class CrashTest { public static void main( String[] args ) { System.out.println(new CrashTest().getText()); } public String getText() { Long lValue1 = getValue1(); Long lValue2 = getValue2(); return ( isValue1() ? "" : ( lValue1 == null ? "" : lValue1.toString() ) + "-" ) + ( lValue2 == null ? "" : lValue2.toString() ); } private Long getValue1() { return Long.valueOf( 1 ); } private Long getValue2() { return Long.valueOf( 1 ); } private boolean isValue1() { return false; } } Causes: Exception in thread "main" java.lang.VerifyError: Inconsistent stackmap frames at branch target 39 Exception Details: Location: CrashTest.getText()Ljava/lang/String; @39: aload_1 Reason: Type uninitialized 26 (current frame, stack[2]) is not assignable to uninitialized 10 (stack map, stack[2]) Current Frame: bci: @31 flags: { } locals: { 'CrashTest', 'java/lang/Long', 'java/lang/Long' } stack: { uninitialized 10, uninitialized 10, uninitialized 26, uninitialized 26, 'java/lang/Long' } Stackmap Frame: bci: @39 flags: { } locals: { 'CrashTest', 'java/lang/Long', 'java/lang/Long' } stack: { uninitialized 10, uninitialized 10, uninitialized 10, uninitialized 10 } Bytecode: 0x0000000: 2ab7 0023 4c2a b700 274d bb00 2a59 2ab7 0x0000010: 002c 9900 0812 30a7 0022 bb00 2a59 2bc7 0x0000020: 0008 1230 a700 072b b600 32b8 0037 b700 0x0000030: 3d12 3fb6 0041 b600 45b8 0037 b700 3d2c 0x0000040: c700 0812 30a7 0007 2cb6 0032 b600 41b6 0x0000050: 0045 b0 Stackmap Table: full_frame(@26,{Object[#1],Object[#51],Object[#51]},{Uninitialized[#10],Uninitialized[#10]}) full_frame(@39,{Object[#1],Object[#51],Object[#51]},{Uninitialized[#10],Uninitialized[#10],Uninitialized[#10],Uninitialized[#10]}) full_frame(@43,{Object[#1],Object[#51],Object[#51]},{Uninitialized[#10],Uninitialized[#10],Uninitialized[#10],Uninitialized[#10],Object[#56]}) full_frame(@57,{Object[#1],Object[#51],Object[#51]},{Uninitialized[#10],Uninitialized[#10],Object[#56]}) same_locals_1_stack_item_frame(@72,Object[#42]) full_frame(@76,{Object[#1],Object[#51],Object[#51]},{Object[#42],Object[#56]}) at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2701) at java.lang.Class.privateGetMethodRecursive(Class.java:3048) at java.lang.Class.getMethod0(Class.java:3018) at java.lang.Class.getMethod(Class.java:1784) at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544) at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)
I will take a look at it.
Created attachment 281385 [details] Proposed patch + regression test Jay, Manoj, could you please deliver this one to master? Thanks.
*** Bug 558821 has been marked as a duplicate of this bug. ***
New Gerrit change created: https://git.eclipse.org/r/155329
(In reply to Eclipse Genie from comment #4) > New Gerrit change created: https://git.eclipse.org/r/155329 Olivier, looking on the patch I wonder why equals() and hashCode() in VerificationTypeInfo.java are not symmetrical. See https://git.eclipse.org/r/#/c/155329/1/org.eclipse.jdt.core/compiler/org/eclipse/jdt/internal/compiler/codegen/VerificationTypeInfo.java@199 and https://git.eclipse.org/r/#/c/155329/1/org.eclipse.jdt.core/compiler/org/eclipse/jdt/internal/compiler/codegen/VerificationTypeInfo.java@206 equals() uses tag, constantPoolName and offset, but hashCode uses tag, constantPoolName and *id*. Bug or feature? If later, I think we should explain this in the code.
(In reply to Andrey Loskutov from comment #5) > Olivier, looking on the patch I wonder why equals() and hashCode() in > VerificationTypeInfo.java are not symmetrical. > equals() uses tag, constantPoolName and offset, but hashCode uses tag, > constantPoolName and *id*. Bug or feature? If later, I think we should > explain this in the code. Looking further, VerificationTypeInfo.hashCode() value is not constant, because all fields from which the hash is computed can be changed after object creation. This is highly dangerous. Is VerificationTypeInfo.hashCode() really used somewhere in the code? If yes, it probably shouldn't be in the current state. But I assume this is not relevant for the current bug, so should I create another one to request removal of current hashCode() implementation from VerificationTypeInfo (should just use Object.hashCode())? The code was added via commit https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=7818c2b6805e0779da46c84f61ed508653a87614 without further explanation.
(In reply to Andrey Loskutov from comment #5) > See > https://git.eclipse.org/r/#/c/155329/1/org.eclipse.jdt.core/compiler/org/ > eclipse/jdt/internal/compiler/codegen/VerificationTypeInfo.java@199 > > and > > https://git.eclipse.org/r/#/c/155329/1/org.eclipse.jdt.core/compiler/org/ > eclipse/jdt/internal/compiler/codegen/VerificationTypeInfo.java@206 > > equals() uses tag, constantPoolName and offset, but hashCode uses tag, > constantPoolName and *id*. Bug or feature? If later, I think we should > explain this in the code. I think it should be consistent. This is a potential bug and yes, these instances are used in an Hashmap so these methods are used.
(In reply to Olivier Thomann from comment #7) > I think it should be consistent. This is a potential bug and yes, these > instances are used in an Hashmap so these methods are used. I would open another bug for that. Can you please point me to the places where VerificationTypeInfo is used in maps/sets?
(In reply to Andrey Loskutov from comment #8) > (In reply to Olivier Thomann from comment #7) > > I think it should be consistent. This is a potential bug and yes, these > > instances are used in an Hashmap so these methods are used. > > I would open another bug for that. Can you please point me to the places > where VerificationTypeInfo is used in maps/sets? This is done in the duplicate() code to handle instances that needs to be the same instance and not a copy. I'll provide a new patch for that. Let's fix it all together.
Created attachment 281389 [details] Proposed patch + regression test New patch for a new gerrit. Jay, I think we should have a quick talk so I know how to setup my environment to trigger gerrit builds myself.
(In reply to Olivier Thomann from comment #10) > Created attachment 281389 [details] > Proposed patch + regression test > > New patch for a new gerrit. I will push it with a small change in the evaluation order in equals, to have slower char[] comparison last in equals() and a call to constantPoolName() instead of this.binding.constantPoolName() in hashCode().
Gerrit change https://git.eclipse.org/r/155329 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=f6ca35bc46a58901d24a836b1dc77576044bdb13
Created attachment 281390 [details] jdt core gerrit config screenshot (In reply to Olivier Thomann from comment #10) > Jay, I think we should have a quick talk so I > know how to setup my environment to trigger gerrit builds myself. Olivier, can I help you? At which step are you failing? Please check https://wiki.eclipse.org/Platform-releng/Git_Workflows#Gerrit_workflow_for_a_committer The most important part is probably that you shouldn't use ssh but fetch/push to https://git.eclipse.org/r/jdt/eclipse.jdt.core.git url, see attached picture for remote configuration. Once you get this remote config done, the only thing to remember is to "amend" commits if you are re-working the same patch.
(In reply to Olivier Thomann from comment #10) > Jay, I think we should have a quick talk so I > know how to setup my environment to trigger gerrit builds myself. Sure, we can catch up soon to set it up if you haven't already done it yourself. And I will soon start creating backport patches as soon as I am bring my current work to conclusion. BTW, thanks Andrey, for the instruction!
CrashTest snippet and snippet from bug 558821 are working now, JDT tests are green too. Closing. Thanks Olivier!
Verified with I20200106-1805
Confirmed the test case derived from Tomcat reported in bug 558821 is also fixed. Tested with I20200107-0600. Thanks for the rapid fix.
*** Bug 559094 has been marked as a duplicate of this bug. ***
*** Bug 559155 has been marked as a duplicate of this bug. ***
Can you please port this to 2019-12 Eclipse or we should wait 2020-03?
(In reply to George Suaridze from comment #20) > Can you please port this to 2019-12 Eclipse or we should wait 2020-03? There will be no backporting to 4.14. You can either pick 4.15 M1 or wait for 4.15. Also you can try build Eclipse from sources by yourself, if this is urgent issue and you need this patch backported to 4.14 build in your project.
Andrey, thanks! I'll give 4.15 M1 a try.
*** Bug 560504 has been marked as a duplicate of this bug. ***
*** Bug 562610 has been marked as a duplicate of this bug. ***
