| Summary: | Eclipse Mars crashes on Mac OS 10.11.4 while compiling with Oracle jdk1.8.0_92 JDK | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Xabriel J Collazo Mojica <xabrielc> | ||||||||
| Component: | Core | Assignee: | Stephan Herrmann <stephan.herrmann> | ||||||||
| Status: | VERIFIED NOT_ECLIPSE | QA Contact: | |||||||||
| Severity: | blocker | ||||||||||
| Priority: | P3 | CC: | ed, frank.van.werven, jarthana, register.eclipse, stephan.herrmann | ||||||||
| Version: | 4.5.2 | ||||||||||
| Target Milestone: | 4.6 RC2 | ||||||||||
| Hardware: | Macintosh | ||||||||||
| OS: | Mac OS X | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
Created attachment 261733 [details]
replay_pid file
Created attachment 261734 [details]
Mac crash report
Looks like the JIT cannot compile one of our classes: Current CompileTask: C2: 349035 16887 4 org.eclipse.jdt.internal.compiler.parser.TypeConverter::decodeType (1094 bytes) --------------- P R O C E S S --------------- Java Threads: ( => current thread ) ... =>0x0000000101804800 JavaThread "C2 CompilerThread2" daemon [_thread_in_native, id=29955, stack(0x00007000010cd000,0x00007000011cd000)] If s.o. identifies the Oracle bug and reports the code scheme that triggers it, we could try to avoid that scheme, but this sure is not an Eclipse bug. As a workaround I suggest you play with the -XX:CompileCommand VM option, see http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html Seems to be this one: https://bugs.openjdk.java.net/browse/JDK-8154831 (In reply to Till Brychcy from comment #4) > Seems to be this one: > https://bugs.openjdk.java.net/browse/JDK-8154831 Thanks, according to that bug, this should be fixed in Oracle Java 9 ea. @Xabriel, is upgrading to early access builds of Java 9 an option for you? Next best solution should be (as per previous comment) -XX:CompileCommand=exclude,org.eclipse.jdt.internal.compiler.parser.TypeConverter::decodeType OTOH, the JDK bug doesn't (yet) have any hints on how to rearrange our source code to avoid triggering this bug. => Nothing we can do on JDT side. Verified for 4.6 RC2. @Stephan Java 9 is not an option for me, but good to know the 'XX:CompileCommand' is a workaround. I understand that JDT can't workaround it. Will track the JVM defect. *** Bug 498283 has been marked as a duplicate of this bug. *** (In reply to Stephan Herrmann from comment #5) > OTOH, the JDK bug doesn't (yet) have any hints on how to rearrange our > source code to avoid triggering this bug. => Nothing we can do on JDT side. It gives a very strong clue "CastII node prematurely goes away and causes a cascade of other eliminations which severely corrupts the graph (the actual crash happens due to a memory edge coming from a non-dominating region). " Looking at TypeConverter::decodeType I see "int start" and numerous "((long) start << 32) + end)" subexpressions. Clearly an unusual and repetitive cast subject to a bad optimization. Suggest an explicit long longStart = start; long offset = (longStart << 32) + end. perhaps an a per-case basis to avoid slowing down the other cases. (In reply to Ed Willink from comment #9) > (In reply to Stephan Herrmann from comment #5) > > OTOH, the JDK bug doesn't (yet) have any hints on how to rearrange our > > source code to avoid triggering this bug. => Nothing we can do on JDT side. > > It gives a very strong clue Thanks for the update, this wasn't present last time I looked :) I filed bug 498527 for the proposed follow-up. Since I've never seen the crash, fixing this would require the help of s.o. who can reproduce the problem and will try our workarounds. Any volunteers? |
Created attachment 261732 [details] hs_err_pid file Eclipse Mars crashes while compiling with Oracle jdk1.8.0_92 JDK. It consistently crashes, rendering Eclipse unusable. If I use Oracle jdk1.8.0_91, the crash goes away. I am attaching: hs_err_pid file replay_pid file Mac crash report