United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-8020433 Crash when using -XX:+RestoreMXCSROnJNICalls
JDK-8020433 : Crash when using -XX:+RestoreMXCSROnJNICalls

Details
Type:
Bug
Submit Date:
2013-07-12
Status:
Closed
Updated Date:
2014-01-14
Project Name:
JDK
Resolved Date:
2013-07-15
Component:
hotspot
OS:
Sub-Component:
compiler
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
hs24,hs25
Fixed Versions:
hs24,hs25 (team)

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Relates:

Sub Tasks

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
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.

                                     
2013-07-12
Maybe related to 8011102?
                                     
2013-07-12
Yes looks like it - as the code change in 8011102 is the only place when RestoreMXCSROnJNICalls is used.
                                     
2013-07-12
I suspect crash happens on first FP op after a JNI call.
                                     
2013-07-12
7u40-defer-request Justification:  P4, and the flag is not used normally
                                     
2013-07-12
SQE is ok to defer from 7u40
                                     
2013-07-12
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()).




                                     
2013-07-12
I will fix it in both hs25 and hs24.

                                     
2013-07-12
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
                                     
2013-07-13
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.

                                     
2013-07-13
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

                                     
2013-07-15
URL:   http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0f57ccdb9084
User:  kvn
Date:  2013-07-15 19:46:24 +0000

                                     
2013-07-15



Hardware and Software, Engineered to Work Together