9

We have the following problem: On some of our Linux machine, Java applications which make use of the trove library and G1 GC will crash rather fast with messages of the following type:

A fatal error has been detected by the Java Runtime Environment:

 SIGSEGV (0xb) at pc=0x00002aaaaaef81d1, pid=31063, tid=1141000512

JRE version: 6.0_29-b11
Java VM: Java HotSpot(TM) 64-Bit Server VM (20.4-b02 mixed mode linux-amd64 )
Problematic frame:
J  gnu.trove.impl.hash.TObjectHash.insertKey(Ljava/lang/Object;)I

What strikes me here is the problematic frame, which is always the same. I'm used to some library appearing here, but never acual Java code. Oddly enough, some machines which ought to have an identical setup are not affected. On Windows, I've also never seen this. The problem persists with recent Java 7 versions. Switching from G1 GC to any other GC resolves the problem immediately. We use trove library as resolved by Maven, tried several versions there, including 3.0.3 - always the same problem.

Does anybody know what could be the reason for this? Any known G1 GC bug? Is trove compiled in a special way which might create this problem?

Update: different application, different server, most recent Java (7u5), similar problem:

A fatal error has been detected by the Java Runtime Environment:

SIGSEGV (0xb) at pc=0x00002aadb7a38093, pid=14100, tid=46925573367184

JRE version: 7.0_05-b05
Java VM: Java HotSpot(TM) 64-Bit Server VM (23.1-b03 mixed mode linux-amd64 compressed oops)
Problematic frame:
J  gnu.trove.map.hash.THashMap.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;

Again, switching to a GC other than G1 will help. Keep G1 but get rid of Trove library, and the problem will also disappear. Unfortunately, I was not able to create a minimal test suite, so it's difficult to file a reasonable bug report. Any ideas on the cause, or any idea which could help me building the test suite?

malamut
  • 456
  • 4
  • 12
  • What VM are you using - OpenJDK or Oracle? Is there a difference depending on what one you use? Is there a difference in bitness (64 / 32 bit) on those machines? – Michael Berry Jul 02 '12 at 12:12
  • 1
    Can you include a crash from Java 7 update 5 to show its still a problem? – Peter Lawrey Jul 02 '12 at 12:22
  • All versions used by us are Oracle 64bit. The latest version we saw this problem with is Java 7u4. Unfortunately, this version had to be removed from our systems due to the critical bug described here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7166379 and here: https://forums.oracle.com/forums/thread.jspa?messageID=10351215 . As I understand, this bug has not been fixed in 7u5, which restricts us to max. 7u3 right now. I'll see whether I can get a 7u5 installed temporarily on one of the affected systems and report back. – malamut Jul 02 '12 at 12:53
  • `Java 1.7.0_17` - the problem still exists. – Andremoniy Apr 08 '13 at 05:17
  • I've just hit this bug. Do you know if upgrading to 1.7.0_40 will fix it? – oxbow_lakes Sep 26 '13 at 10:29
  • @oxbow_lakes: sorry, I don't know. We finally dumped G1 because we felt it got increasingly buggy during the versions of 2011/2012. This decision dates back to end of 2012, though; things might have improved in the meantime. Please go ahead, try 1.7.0_40, and report the result here. – malamut Sep 27 '13 at 11:19
  • Still broken as of 1.7.0_u45 – oxbow_lakes Nov 22 '13 at 09:18

2 Answers2

3

G1GC isn't "ready for use" in Java 6; It's only in Java 7u4 that it finally became production ready. See http://phosphor-escence.blogspot.com/2012/05/java7u4-enables-g1gc-without.html for a note on it, and there's more on Google, of course.

Joseph Ottinger
  • 4,911
  • 1
  • 22
  • 23
3

It appears that this is indeed a JDK bug, https://bugs.openjdk.java.net/browse/JDK-8023472, fixed by Java 7 update 65+.

Kimoon
  • 46
  • 2
  • We have never used that specific Java release, but I can confirm that the issue is fixed in Java 8 Update 45. So I guess that was indeed the culprit. Finally! :) – malamut May 22 '15 at 07:55