Crash: Java_com_ibm_oti_vm_VM_getClassNameImpl+0x63 (java_lang_class.cpp:281, 0x00007FFFFE6C87A3 [jclse7b_29+0x87a3])

After upgrading to Domino 901FP9, the latest jRebel version crashed the server. But not all server with this combination of software releases. With FP10 it got worse; now the crash was reproducible on all servers.

I created a PMR with IBM and the issue is tracked under SPR# OSAMAVRQKN

The above crash is easily recreatable locally without Domino or jRebel involved with JAVA 8 release.

On Windows:

  • set JREDIR= …
  •  %JREDIR%\bin\java -Dcom.ibm.oti.vm.bootstrap.library.path=%JREDIR%\bin\default;%JREDIR%\bin -version

On Linux:

  • export JREDIR= …
  • $JREDIR/bin/java -Dcom.ibm.oti.vm.bootstrap.library.path=$JREDIR/lib/amd64/default:$JREDIR/lib/amd64 -version

I did further testing with various java releases.

The first non-working level reproducing this crash for each java release is given below:

  • JAVA 6/26 SR5
  • JAVA 7 SR4
  • JAVA 7.1 GA
  • JAVA 8 GA

Above test results indicate that crash doesn’t happen at JAVA 6/26 SR4 or below. Crash doesn’t occur at JAVA 7 SR3 or below. JAVA 7.1 and JAVA 8 releases reproduce this crash from General Availability onwards.

Complete JAVA 6 release doesn’t reproduce this crash and runs fine including the latest build.

Today I got a response from the J9VM support team.

In old versions of JDK, by default we are using nocompressedrefs (meaning -Xnocompressedrefs). So jre/lib/amd64/default is the one where we find all the JVM native libraries.

In newer versions of JDK, by  default we are using compressedrefs (meaning -Xcompressedrefs). So jre/lib/amd64/compressedrefs is the one where we find all the JVM native libraries.

Therefore it would cause native library mis-match if you use -Dcom.ibm.oti.vm.bootstrap.library.path=jre/lib/amd64/default for -Xcompressedrefs.

The following commands will fail (becaue it would have native library mis-match):

  • <Path>/jre/bin/java -Dcom.ibm.oti.vm.bootstrap.library.path=<Path>/jre/lib/amd64/default   -version
  • <Path>/jre/bin/java -Xcompressedrefs -Dcom.ibm.oti.vm.bootstrap.library.path=<Path>/jre/lib/amd64/default -version
  • <Path>/jre/bin/java -Xnocompressedrefs  -Dcom.ibm.oti.vm.bootstrap.library.path=<Path>/jre/lib/amd64/compressedrefs -version

The following commands will be OK (becaue it would not have native  library mis-match):

  • <Path>/jre/bin/java -Dcom.ibm.oti.vm.bootstrap.library.path=<Path>/jre/lib/amd64/compressedrefs -version
  • <Path>/jre/bin/java -Xcompressedrefs -Dcom.ibm.oti.vm.bootstrap.library.path=<Path>/jre/lib/amd64/compressedrefs -version
  • <Path>/jre/bin/java -Xnocompressedrefs  -Dcom.ibm.oti.vm.bootstrap.library.path=<Path>/jre/lib/amd64/default -version

 

Post Views: 1,203

One thought on “Crash: Java_com_ibm_oti_vm_VM_getClassNameImpl+0x63 (java_lang_class.cpp:281, 0x00007FFFFE6C87A3 [jclse7b_29+0x87a3])”

  1. I still have all production servers at FP8. Guess they will remain that way for the foreseeable future. Makes me wonder if too many of the veteran IBM team are now gone. Certainly not as much testing as in previous years. Maybe they should prerelease builds to business partners? FP9 and FP10 had too many issues at release.
    Or perhaps the code is now compiled by a different team overseas? Hopefully things will get better in the upcoming months…. customer since version 3.

Comments are closed.