JDK-8020433 : Crash when using -XX:+RestoreMXCSROnJNICalls
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs24,hs25
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • CPU: x86
  • Submitted: 2013-07-12
  • Updated: 2014-02-05
  • Resolved: 2013-07-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 Other
7u40Fixed 8Fixed hs24Fixed
Related Reports
Relates :  
JDK-8011102 - Clear AVX registers after return from JNI call
Description
When running with -XX:+RestoreMXCSROnJNICalls on Linux/amd64 I get a crash:

jdk1.7.0_40-b33/bin/java -XX:+RestoreMXCSROnJNICalls Foo
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGFPE (0x8) at pc=0x00007fa3879ec3be, pid=18299, tid=140340350891776
#
# JRE version: (7.0_40-b33) (build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b52 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# V [libjvm.so+0x80a3be] os::elapsedTime()+0x2e
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /tmp/hs_err_pid18299.log

This appears to be new in 7u40 - I do not see the crash with 7u25.

ILW=HLL=P4
Comments
7-critical-request justification: RestoreMXCSROnJNICalls is used by sustaining group to help customers debug their problem. We need to restore this functionality since it worked before 8011102 changes. Small safe changes. The fix will be pushed into hs25/jdk8 and will be tested first. http://cr.openjdk.java.net/~kvn/8020433/webrev/ Note, create_control_words() in stubGenerator_x86_64.cpp is not new code, it is copied from stubGenerator_x86_32.cpp
15-07-2013
Thank you, John We will do 8020484 later for jdk8 only. Note hs24/jdk7 does not have stubRoutines_x86.cpp so we can't do that in hs24 without doing a lot of changes.
15-07-2013
Suggestion: Move sharable code from stubGenerator_x86_32.cpp to stubRoutines_x86.cpp. For the general task of merging x86 code, I filed JDK-8020484
13-07-2013
I will fix it in both hs25 and hs24.
12-07-2013
It is mess (as usual) :) inherited from x86-32 and amd64 sources merge long time ago. The webrevs are long gone since they were removed from prt-archive because we periodically getting out of disk space. So it is difficult to recover old history. The current state: - there are 2 different variables in which we keep standard mxcsr value: StubRoutines::_mxcsr_std StubRoutines::x86::_mxcsr_std - The problem is: StubRoutines::_mxcsr_std is only initialized in 32-bit VM StubRoutines::x86::_mxcsr_std is only initialized in 64-bit VM In my changes for 8011102 I did not realized it and used StubRoutines::_mxcsr_std in all places (I factored similar code in one method restore_cpu_control_state_after_jni()).
12-07-2013
SQE is ok to defer from 7u40
12-07-2013
7u40-defer-request Justification: P4, and the flag is not used normally
12-07-2013
I suspect crash happens on first FP op after a JNI call.
12-07-2013
Yes looks like it - as the code change in 8011102 is the only place when RestoreMXCSROnJNICalls is used.
12-07-2013
Maybe related to 8011102?
12-07-2013
Crash is early in VM initialization: Stack: [0x00007f47cd41f000,0x00007f47cd520000], sp=0x00007f47cd51d710, free space=1017k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x808e4e] os::elapsedTime()+0x2e V [libjvm.so+0x4a1535] Events::log(Thread*, char const*, ...)+0xf5 V [libjvm.so+0x50b23a] EventMark::EventMark(char const*, ...)+0xca V [libjvm.so+0x40bc77] ClassLoader::load_classfile(Symbol*, Thread*)+0x77 V [libjvm.so+0x90b6d7] SystemDictionary::load_instance_class(Symbol*, Handle, Thread*)+0x3a7 V [libjvm.so+0x90bee1] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*)+0x781 V [libjvm.so+0x90c344] SystemDictionary::resolve_or_null(Symbol*, Handle, Handle, Thread*)+0x54 V [libjvm.so+0x90d434] SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, Thread*)+0x34 V [libjvm.so+0x48cd48] constantPoolOopDesc::klass_at_impl(constantPoolHandle, int, Thread*)+0x278 V [libjvm.so+0x5ef9c4] InterpreterRuntime::_new(JavaThread*, constantPoolOopDesc*, int)+0x74 j java.lang.Thread.<clinit>()V+10 v ~StubRoutines::call_stub V [libjvm.so+0x5f7735] JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x365 V [libjvm.so+0x5f6198] JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*)+0x28 V [libjvm.so+0x5ba61a] instanceKlass::call_class_initializer(Thread*)+0xca V [libjvm.so+0x5ba874] instanceKlass::initialize_impl(instanceKlassHandle, Thread*)+0x234 V [libjvm.so+0x5bacca] instanceKlass::initialize(Thread*)+0x6a V [libjvm.so+0x94369c] Threads::create_vm(JavaVMInitArgs*, bool*)+0x5fc V [libjvm.so+0x629294] JNI_CreateJavaVM+0x74 C [libjli.so+0x2f8e] JavaMain+0x9e Seems to have been introduced in b23, though the crash can also manifest as a SIGFPE in the same method.
12-07-2013