Trove and G1GC compatibility

Issue #45 invalid
prabhu damodharan created an issue

usage of G1GC strategy for garbage collection results in JVM crash with the following the error

# A fatal error has been detected by the Java Runtime Environment:
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000002aa8329, pid=5348, tid=4788
# JRE version: Java(TM) SE Runtime Environment (7.0_40-b43) (build 1.7.0_40-b43)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b56 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# J  gnu.trove.impl.hash.TObjectHash.insertKey(Ljava/lang/Object;)I
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
# If you would like to submit a bug report, please visit:

Comments (7)

  1. Rob Eden

    That's going to be a problem with the JVM, not Trove. There should be no pure Java code that can be written that could crash the JVM and Trove is pure Java (with no "sun.misc.Unsafe" silliness or anything like that).

  2. Scott Banachowski

    I've encountered the same crash when switching from Java 6 to Java 7. It's also been reported/discussed by others on stack overflow:

    From what I've read, if you get a SEGV from compiled java code, it is likely due to a compiler bug that has resulted in incorrect code generation. I'm wondering if the jar we retrieved from the online artifact has an incompatibility with Java 7. Perhaps compiling the jar ourselves with a java 7 compiler might help.

  3. Rob Eden

    @sbanacho - It still shouldn't really be able to cause the problem. The fault for the crash would still lay with the GC. That being said... dunno, it may help. How often do you see the problem? Would you be able to call it "fixed" if you didn't see a crash after some amount of time?

    There's really nothing interesting happening with the insertKey method. No idea why the GC would be unhappy with it.

  4. IceMan81

    @kimoon @robeden Sorry about commenting on a closed issue, but I'm seeing a somewhat similar issue where the JVM crashes due to some bad optimization by the C2 Compiler. This is using the latest JDK 8u92 and trove 3.0.3. Everytime that particular piece of code runs, the JVM crashes; it is on the insertKey method. Trying to find out if others have seen similar issues?

  5. Log in to comment