Community
Participate
Working Groups
Created attachment 252853 [details] hs_err_pid7260.log I20150428-0100, Oracle JDK 1.8.0_40-b25 Yesterday and today, I've had two random VM crashes that occurred out of the blue. I didn't change the JRE recently. I'm just filing this bug to have a searchable target in case I or others run into it again. I know the right location for this bug would be http://bugreport.java.com/bugreport/crash.jsp , but that's an inaccessible path that rarely ever helps anyone. For both incidents, the "Native frames:" and "Current CompileTask:" sections are the same. # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000006513614f, pid=7260, tid=8664 # # JRE version: Java(TM) SE Runtime Environment (8.0_40-b25) (build 1.8.0_40-b25) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.40-b25 mixed mode windows-amd64 compressed oops) # Problematic frame: # V [jvm.dll+0x4b614f] PhaseIdealLoop::build_loop_late_post+0x1bf [..] --------------- T H R E A D --------------- Current thread (0x00000000097ad000): JavaThread "C2 CompilerThread1" daemon [_thread_in_native, id=8664, stack(0x000000000b8b0000,0x000000000b9b0000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0000000000000008 [..] Stack: [0x000000000b8b0000,0x000000000b9b0000], sp=0x000000000b9abe50, free space=1007k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0x4b614f] PhaseIdealLoop::build_loop_late_post+0x1bf V [jvm.dll+0x4b7959] PhaseIdealLoop::build_loop_late+0x229 V [jvm.dll+0x4b983f] PhaseIdealLoop::build_and_optimize+0x6ef V [jvm.dll+0x46bf81] Compile::Optimize+0xc21 V [jvm.dll+0x46ccbe] Compile::Compile+0xb4e V [jvm.dll+0x4500d2] C2Compiler::compile_method+0xa2 V [jvm.dll+0xa4312] CompileBroker::invoke_compiler_on_method+0x472 V [jvm.dll+0xa4c4f] CompileBroker::compiler_thread_loop+0x2ef V [jvm.dll+0x241914] JavaThread::thread_main_inner+0xb4 V [jvm.dll+0x29848a] java_start+0x8a C [msvcr100.dll+0x21d9f] C [msvcr100.dll+0x21e3b] C [kernel32.dll+0x159cd] C [ntdll.dll+0x2b891] Current CompileTask: C2:7274868 48209 4 org.eclipse.jdt.internal.compiler.parser.TypeConverter::decodeType (1094 bytes) [..]
The crashes continued and completely blocked my work. -Xint is too slow to get anything done. But this helped up to now: -XX:CompileCommand=exclude,org/eclipse/jdt/internal/compiler/parser/TypeConverter.decodeType
I can reproduce the problem with my main workspace (can't share) with these steps: - launch my workspace "master" with jdk8_60-ea-bin-b12 - set breakpoint in org.eclipse.e4.ui.model.application.ui.basic.impl.PartImpl#setIconURI(String) - launch my runtime workspace "runtime-head-CLEAN (2)" - when breakpoint is hit, hover over the method parameter "newIconURI" => often crashes the first time -- otherwise, hover something else and then hover the parameter again. I can't reproduce in a new workspace.
Probably https://bugs.openjdk.java.net/browse/JDK-8078262
(In reply to Markus Keller from comment #3) Reading JDK-8078262 , there seems to be a workaround: " The only known workaround (-XX:-UseLoopPredicate) has an impact on performance. The bug was reported by a customer and should be fixed in 8u60 if possible. " Have you tried with -vmargs -XX:-UseLoopPredicate ?
https://bugs.openjdk.java.net/issues/?jql=text%20~%20%22\%22PhaseIdealLoop%3A%3Abuild_loop_late_post\%22%22%20ORDER%20BY%20updated%20DESC finds more dups, e.g. https://bugs.openjdk.java.net/browse/JDK-8087109 A comment from https://bugs.openjdk.java.net/browse/JDK-8078262: > It may be necessary to run it several times before seeing the crash. [..] > with 4 cores, approximately 1 of 10 runs crashes. > > It was reported the probability of the crashes depends on the number of cores > - with 8 cores, the crash is said to be more likely. I do have 8 cores, and I got the same crash with 1.9.0-ea-b63 as well (after working for a while). I've only started seeing this after having moved from 1.7 to 1.8. However, some people already had crashes in "PhaseIdealLoop::build_loop_late_post" in 1.6: https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/1212931 (In reply to Martin Oberhuber from comment #4) > Have you tried with -vmargs -XX:-UseLoopPredicate ? Yes, I've been running with that for a day without any problems, and performance still feels fine. Workaround from comment 1 also worked reliably. I initially thought this could need a readme entry, but since nobody else has found this bug in almost 2 months, it's probably a very machine-specific issue.
The VM bug has been confirmed and Oracle is working on a fix for Java 9. Workaround is to add either of these VM arguments: -XX:-UseLoopPredicate -XX:CompileCommand=exclude,org/eclipse/jdt/internal/compiler/parser/TypeConverter.decodeType
This may indeed be a NOT_ECLIPSE problem but it makes Eclipse unuseable with Java 8. I get Java crashes about every two hours. No way. The workaround must be built into the Eclipse.ini or better as default. We can't expect users to discover this problem.
(In reply to Martin Oberhuber from comment #4) > "should be fixed in 8u60 if possible. " More recent comments suggest that the fix is hard and dangerous and so should be deferred till Java 9. Since the underlying problem appears to be a missing dependency and is rare, perhaps a minor rearrangement such as some explicit local variables for complex expressions in org/eclipse/jdt/internal/compiler/parser/TypeConverter.decodeType might just make the problem go away.
decodeType(char[], int, int, int, boolean) was the problematic method. I tried a few small-scale changes like avoiding the "typeLoop:" label or creating a "TypeReference result" variable and assigning return values to that variable and then calling "return result", but this didn't resolve the crashes. Extracting the second part of the method into a separate method helped. No crashes so far. I also gave the methods unique names to make them easier to identify. Fixed with http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=ff69704e7873da2fd087fbac19e278c5d6c62ca3 Keeping bug open for backport to 4.5.1.
+1 for 4.5.1.
Fixed in R4_5_maintenance with http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=6981d220715852ae5403266f01e3ec34f3537e25
Verified for 4.5.1 based on comment 9 and inspection. I could not reproduce the crash on any of the workspaces I have.
Hm, I assume this is not fixed in 4.5.2. Or not completely worked around. I run into a crashs multiple times. Using the VM arguments works, just want to inform, that this problem still exists. Version: Mars.2 Release (4.5.2) Build id: 20160218-0600 Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0 org.eclipse.m2e.logback.configuration: The org.eclipse.m2e.logback.configuration bundle was activated before the state location was initialized. Will retry after the state location is initialized. Starting Groovy-Eclipse compiler resolver. Specified compiler level: unspecified 54 2.3.10.xx-201604081629-e45 = STARTING org.eclipse.m2e.logback.configuration: Logback config file: /home/rathgeb/bin/pkgs/eclipse/esh/ws/.metadata/.plugins/org.eclipse.m2e.logback.configuration/logback.1.6.2.20150902-0002.xml SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [bundleresource://648.fwk794940817:1/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [bundleresource://648.fwk794940817:2/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder] org.eclipse.m2e.logback.configuration: Initializing logback No bp log location saved, using default. [000:000] Cpu: 6.60.3, x4, 2501Mhz, 7866MB [000:000] Computer model: Not available [000:000] Browser XEmbed support present: 1 [000:000] Browser toolkit is Gtk2. [000:004] Using Gtk2 toolkit [000:004] Warning(optionsfile.cc:30): Load: Could not open file, err=2 [000:004] No bp log location saved, using default. [000:005] Cpu: 6.60.3, x4, 2501Mhz, 7866MB [000:005] Computer model: Not available [000:005] Browser XEmbed support present: 1 [000:005] Browser toolkit is Gtk2. [000:005] Using Gtk2 toolkit No bp log location saved, using default. [000:000] Cpu: 6.60.3, x4, 2501Mhz, 7866MB [000:000] Computer model: Not available [000:000] Warning(optionsfile.cc:30): Load: Could not open file, err=2 [000:000] No bp log location saved, using default. [000:000] Cpu: 6.60.3, x4, 2501Mhz, 7866MB [000:000] Computer model: Not available # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f66394e3c24, pid=3107, tid=0x00007f660ba0c700 # # JRE version: Java(TM) SE Runtime Environment (8.0_92-b14) (build 1.8.0_92-b14) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.92-b14 mixed mode linux-amd64 compressed oops) # Problematic frame: # V [libjvm.so+0x815c24] PhaseIdealLoop::build_loop_late_post(Node*)+0x144 # # Core dump written. Default location: /home/rathgeb/core or core.3107 # # An error report file with more information is saved as: # /home/rathgeb/hs_err_pid3107.log # # Compiler replay data is saved as: # /home/rathgeb/replay_pid3107.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp #
(In reply to Markus Rathgeb from comment #13) > Hm, I assume this is not fixed in 4.5.2. This bug has been fixed in JDT Core in 4.5.1 and later (including 4.5.2 and 4.6). > Starting Groovy-Eclipse compiler resolver. [..] You're probably not using the official Eclipse JDT compiler. Groovy replaces the JDT bundles with a hacked version, and I don't know whether they ship a version that includes 4.5.1 nor whether you have actually installed it. Try uninstalling or upgrading Groovy.
> You're probably not using the official Eclipse JDT compiler. Groovy replaces > the JDT bundles with a hacked version, and I don't know whether they ship a > version that includes 4.5.1 nor whether you have actually installed it. Try > uninstalling or upgrading Groovy. Thank you for pointing this out. It is correct that the Eclipse SmartHome setup uses the feature "org.codehaus.groovy.eclipse.feature.feature.group". I will have a look at. Thanks ;)
Thanks for this workaround! I started encountering this issue a little while ago in one of my workspaces (I have a few dozen it was never a problem in) - even recreating the workspace did not solve the issue. I've been running for a few days now without issues
*** Bug 506370 has been marked as a duplicate of this bug. ***
