1

There is a similar stackoverflow question SIGSEGV Java Fatal Error in libjvm.so regarding this problem.

This is a large application (~30GB) running under apache tomcat. Seems to always fail with the same error message, which appears to be inside JVM C++ code:

V  [libjvm.so+0x643ee4]  InstanceKlass::find_method_index(Array<Method*>*, Symbol*, Symbol*, bool, bool)+0x14

I've included the full java core dump.

https://drive.google.com/open?id=0B0rh8NWt2kRySTlleW9Dckw3a3c

Can anyone point me in the right direction for how to even begin to solve this issue. I have tried to upgrade the JDK to the latest release level (JDK 1.8 release 144), to no avail.

user3892260
  • 965
  • 2
  • 10
  • 19
  • 1
    I'm looking through the dump. This is independent from your problem, but your classpath of your webapp is quite crowded and you're happily mixing libraries of different versions, e.g. two Bouncy Castle provider jars with different versions and additional bc-libraries of yet other versions. These jars are signed so I'm surprised that this actually works, because the ClassLoader should throw an error when trying to load BC-classes from different jars and different versions. Oh, and the bc-library are compiled for Java 1.4 and you're using Java 8. – Lothar Sep 19 '17 at 21:07

1 Answers1

1

Looking at the dump, it seems that the problem occurred while Hotspot was trying to do optimization. So I checked the java properties you set during startup and there are a bit that have an impact on that:

-Xnoclassgc

This has no use with Java 8 anymore as far as I know. Same with

-XX:MaxPermSize=256m

You're changing the Garbage Collector to be used tp G1.

-XX:+UseG1GC

This might have something to do with the crash, so my suggestion is to change the setting back to use the default one. If the crash disappears, G1 isn't for your application.

And as I mentioned in my comment, you need to clean up your webapp's lib-directory. There are many duplicate libraries of different versions, e.g. bcprov-jdk14-140.jar and bcprov-jdk14-1.38.jar, bcmail-jdk14-139.jar and bcmail-jdk14-1.38.jar, ... This doesn't crash your application the way you've seen, but it should lead to signature verification check failues within the class loader when trying to load mail-classes from bcmail of version 1.39 while working with BC-provider of version 1.40.

Lothar
  • 5,323
  • 1
  • 11
  • 27
  • I can try those things, they sound like reasonable adjustments, although the same exact VM arguments are used elsewhere and the JVM never crashes there. – user3892260 Sep 20 '17 at 13:22
  • i cleaned up the maven pom.xml to avoid loading duplicate items. let's see if it helps – user3892260 Sep 21 '17 at 21:09
  • 1
    After many weeks of trying different permutations, I have isolated the problem to using the G1GC. If I omit that setting and let it use the standard G1 garbage collector, the problem stops. Thanks Lothar for your suggestions. – user3892260 Oct 25 '17 at 16:11