Bugzilla – Full Text Bug Listing
| Summary: | hotswap crashes JVM (bad stackmap) | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Nathan Sweet <misc> |
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
| Status: | CLOSED MOVED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | badlogicgames, jarthana, loskutov, manoj.palat, Olivier_Thomann, sarika.sinha, simeon.danailov.andreev |
| Version: | 4.7.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 10 | ||
| Whiteboard: | stalebug | ||
| Attachments: | |||
Created attachment 283699 [details]
jdk-1.7.0_45 crash dump.
Reproduced the crash with Java 7, 8, and 13.0+33. Debugging the Java 13 JVM, it appears the code that crashes is trying to reconstruct which slots on the stack need to be collected by the GC. Doing that uses the the stackmap, the stackmap from Eclipse is wrong, and so it crashes. Created attachment 283700 [details]
jdk-13.0+33 crash dump.
I see there is an agent added, most likely the one that is enabled if advanced debug source lookup is enabled. Can you please disable this option and try again? I fear the agent haven't properly modified loaded class file. The crash still occurs when "Java > Debug > Use advanced source lookup (JRE 1.5 and higher)" is unchecked. Created attachment 283702 [details]
jdk-13.0+33 crash dump (without advanced source lookup).
Can confirm the crash with JDT head as of today and Java 1.8.0_191 / 11.0.8. 11.0.8 is giving better error that the class file is invalid: # Internal Error (./open/src/hotspot/share/oops/generateOopMap.cpp:2164), pid=2400, tid=248 # fatal error: Illegal class file encountered. Try running with -Xverify:all in method setText Eclipse 4.15 does not crash JVM, so this is a regression in 4.16. Olivier: could you please take a look? (In reply to Andrey Loskutov from comment #7) > Eclipse 4.15 does not crash JVM, so this is a regression in 4.16. I'm sorry, I did a small mistake in reproducing with 4.15, the breakpoint must be at exact the commented line. I see same crash with all versions back to 4.7.2 inclusive (haven't tried earlier versions yet). Keeping Sarika in the CC, who might have some idea about this. I think I have seen a bug like this, will have to dig out. It happens because the static nature of the class GlyphLayout. Removing the static nature makes the hot code replacement work well. Possibly Debug can warn for these case. FWIW, the original GlyphLayout class where this was found is not static: https://github.com/libgdx/libgdx/blob/master/gdx/src/com/badlogic/gdx/graphics/g2d/GlyphLayout.java I haven't tried changing the chopped up version of GlyphLayout used to create the standalone repro attached to this issue, but I expect it to crash even when GlyphLayout is a top level class. Created attachment 283765 [details]
EclipseHotswapCrash_withoutstatic
This version does not crash on Mac.
@Sarika Your "EclipseHotswapCrash_withoutstatic" attachment cannot run because you've made GlyphRun non-static, so the Pool class can no longer create an instance. Also note you changed the if test from "ab" to "ac" so a breakpoint set at the indicated position will never be hit. I agree it may be helpful to show what changes to the reproduction cause the problem to go away, but it should be runnable and I think it is most useful to make only the smallest possible changes to the original that cause the problem to go away. If you take the original and make no other changes except removing "static" from the declaration of the fields "glyphRunPool" and "colorPool", then the hotswap succeeds without crashing. Note I used a native debugger and it appears that Eclipse provides the JVM with a bad stackmap. (In reply to Nathan Sweet from comment #13) > Note I used a native debugger and it appears that Eclipse provides the JVM > with a bad stackmap. I think we have not a debugger issue here, but incremental ECJ compiler issue, stackmap data is read from .class files, not supplied via JVMTI. I guess incremental change corrupts stack map in some way. The bug is quite old, must be really a very special corner case in compiler. (In reply to Nathan Sweet from comment #13) > @Sarika Your "EclipseHotswapCrash_withoutstatic" attachment cannot run > because you've made GlyphRun non-static, so the Pool class can no longer > create an instance. Also note you changed the if test from "ab" to "ac" so a > breakpoint set at the indicated position will never be hit. > I did run with "ab". "ac" was after the edit. I'm getting this stack map corruption quite refularly as well on JDK 15 and JDK 16. If someone could point me at the code in ECJ that generates the stack map, I could have a look. (In reply to Mario Zechner from comment #16) > I'm getting this stack map corruption quite refularly as well on JDK 15 and > JDK 16. If someone could point me at the code in ECJ that generates the > stack map, I could have a look. Thanks Mario for offering to take a look: The org.eclipse.jdt.internal.compiler.ClassFile class have generateStackMapAttribute and generateStackMapTableAttribute methods to generate stackmaps. The CodeStream class via various generate instruction methods keeps track of the stack state as well. 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. The crash still repros in 2023-03 (4.27) I20230220-0920. I still get this hotwap crash periodically during normal, real world usage. It isn't super often but something is obviously wrong and it may be indicative of other problems. @Nathan, project bug tracker moved to https://github.com/eclipse-jdt/eclipse.jdt.core/issues Could you please create bug there with a summary / all provided reproducer examples? Thanks. I've opened an issue: https://github.com/eclipse-jdt/eclipse.jdt.core/issues/925 https://bugs.openjdk.org/browse/JDK-8307331 was opened, it was determined the JVM has a bug when redefining a class. Line mappings returned by the JVM are not updated in some case, see the request from Eclipse here: https://github.com/eclipse-jdt/eclipse.jdt.debug/blob/master/org.eclipse.jdt.debug/jdi/org/eclipse/jdi/internal/MethodImpl.java#L164 |
Created attachment 283698 [details] EclipseHotswapCrash.java: has Java method that crashes when hotswapped. Reproduction: 1) Load the attached EclipseHotswapCrash.java in Eclipse. 2) Set a breakpoint on the println (line 24). 3) Run, when breakpoint is hit, modify the string "ab" to "abc", and save the file. Result: The JVM crashes.