JDK-8038633 : crash in VM_Version::get_processor_features() on startup
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8u20,9
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-03-28
  • Updated: 2017-08-08
  • Resolved: 2014-03-31
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 8 JDK 9
8u20Fixed 9 b08Fixed
Description
Running java -version or HelloWorld with Windows x86 version of 8u20-b07 crashes in VM_Version::get_processor_features(). 

00 00e0f894 593d9632 0x2a20202
01 00e0fa08 593da344 jvm!VM_Version::get_processor_features+0x52 [c:\re\workspace\8-2-build-windows-i586-cygwin\jdk8u20\2572\hotspot\src\cpu\x86\vm\vm_version_x86.cpp @ 398]
02 00e0fb08 59313855 jvm!VM_Version::initialize+0x94 [c:\re\workspace\8-2-build-windows-i586-cygwin\jdk8u20\2572\hotspot\src\cpu\x86\vm\vm_version_x86.cpp @ 930]
03 00e0fb30 59337608 jvm!init_globals+0x35 [c:\re\workspace\8-2-build-windows-i586-cygwin\jdk8u20\2572\hotspot\src\share\vm\runtime\init.cpp @ 100]
04 00e0fc28 592a9d01 jvm!Threads::create_vm+0x1b8 [c:\re\workspace\8-2-build-windows-i586-cygwin\jdk8u20\2572\hotspot\src\share\vm\runtime\thread.cpp @ 3424]
05 00e0fc64 00d913c1 jvm!JNI_CreateJavaVM+0x51 [c:\re\workspace\8-2-build-windows-i586-cygwin\jdk8u20\2572\hotspot\src\share\vm\prims\jni.cpp @ 5187]
06 00e0fc8c 00d91e7e java+0x13c1
07 00e0fcd4 00d9ab81 java+0x1e7e
08 00e0fd0c 00d9ac0b java+0xab81
09 00e0fd18 761f495d java+0xac0b
0a 00e0fd24 77e198ee KERNEL32!BaseThreadInitThunk+0xe

Both machines where it has been seen are Sandy Bridge machines running Windows. 

ILW HHH = P1
I: High, Crashes
L: High, Crashes every time
W: High, No known workaround at this time
Comments
Even when AVX is present some Windows OS switch YMM registers off (xem_xcr0_eax.ymm bit is 0): std_cpuid1_ecx : 0x7dfefbff xem_xcr0_eax : 0x00000003 That is why JVM does not crush on those machines - we don't execute segv code when YMM registers are not supported.
29-03-2014
[D:/AIXPPC/8038633/8038633_3] bin/java -server -version VM_Version::initialize() call getPsrInfo_stub Execution protection violation at 0x01530282 continue in VM_Version::cpuinfo_cont_addr() return from getPsrInfo_stub java version "1.8.0-fastdebug" Java(TM) SE Runtime Environment (build 1.8.0-fastdebug-b132) Java HotSpot(TM) Server VM (build 25.20-b08-internal-201403282259.vkozlov.8038633_8u-fastdebug, mixed mode)
28-03-2014
Hurray! Following example in jni.cpp helped: + // Some platforms (like Win*) need a wrapper around here + // in order to properly handle SEGV for YMM registers test. + CALL_TEST_FUNC_WITH_WRAPPER_IF_NEEDED(getPsrInfo_wrapper); Now I have to find why on some machines the test passed before.
28-03-2014
Leonid, I think you should create a separate bug for infra issue. This one is for the Hotspot problem.
28-03-2014
May be on win32 I have to do something similar to NX check: #ifndef _WIN64 void nx_check_protection() { // If NX is enabled we'll get an exception calling into code on the stack char code[] = { (char)0xC3 }; // ret void *code_ptr = (void *)code; __try { __asm call code_ptr } __except(nx_exception_filter((_EXCEPTION_POINTERS*)_exception_info())) { tty->print_raw_cr("NX protection detected."); } } #endif // _WIN64
28-03-2014
Who is expert on signal handling in VM on Windows? I want to know when topLevelExceptionFilter() is executed because after I added print statements into it I don't see output from them when crash happened: [D:/AIXPPC/8038633/8038633_2] bin/java -version VM_Version::initialize() cpuinfo_cont_addr() : 0x01390204 call getPsrInfo_stub [1] + Done(139) bin/java -version 1512 Segmentation violation bin/java
28-03-2014
Leonid, it affects only 32 windows, 32 bits version aren't very common in our XXI century. Also initially, is was mentioned that not all arches are affected. RSo its likelihood is low or medium.
28-03-2014
Confirmed that on this machine the push into jdk9 hs-comp does not work too: [D:/AIXPPC/8038633/8037226_9] bin/java -server -Xinternalversion Java HotSpot(TM) Server VM (25.0-b62-internal-201403150031.vkozlov.8037226-fastdebug) for windows-x86 JRE (1.8.0), built on Mar 15 2014 01:41:04 by "jprtadm" with MS VC++ 10.0 (VS2010) [D:/AIXPPC/8038633/8037226_9] bin/java -server -version [1] + Done(139) bin/java -server -version 3848 Segmentation violation bin/java
28-03-2014
>>ILW=HLH=>P2 >> L: Low, not all arches are affected + it happens on only windows it is not L it is H one of platforms is completely broken!
28-03-2014
This doesn't seem to have been found in our testing, original report came from Claes in perf who pinged me about not being able to run on 32bit Windows and I looked into it.
28-03-2014
Good question. This code was pushed into current jdk9 hotspot hs-comp repo 2 weeks ago. And we did not see issues.
28-03-2014
I don't see any info about nightly failures. Why?
28-03-2014
Happens on my Ivy Bridge too. I don't agree that Likelihood is Low, it reproduces every time on one of the most used OS configurations we have on at least two of the most popular CPU architectures.
28-03-2014
Confirmed that 64-bit VM works: [D:/AIXPPC/8038633/8037226_64b] bin/java -version java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) 64-Bit Server VM (build 25.20-b07-internal-201403201748.vkozlov.8037226_8u, mixed mode)
28-03-2014
The system info: Logical CPUs per core: 2 UseSSE=4 UseAVX=1 UseAES=1 Allocation prefetching: PREFETCHNTA at distance 192, 4 lines of 64 bytes ContendedPaddingWidth 128 CPU:total 32 (8 cores per cpu, 2 threads per core) family 6 model 45 stepping 7, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, avx, aes, clmul, ht, tsc, tscinvbit, tscinv
28-03-2014
ILW=HLH=>P2 L: Low, not all arches are affected + it happens on only windows
28-03-2014
And it fails with my 8037226 push: [D:/AIXPPC/8038633/8037226] bin/java -server -Xinternalversion Java HotSpot(TM) Server VM (25.20-b07-internal-201403201748.vkozlov.8037226_8u) for windows-x86 JRE (1.8.0), built on Mar 20 2014 19:30:54 by "jprtadm" with MS VC++ 10.0 (VS2010) [D:/AIXPPC/8038633/8037226] bin/java -server -version [1] + Done(139) bin/java -server -version 1372 Segmentation violation bin/java
28-03-2014
Or my code in os_windows.cpp does not work: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/diff/8867fec28aa1/src/os/windows/vm/os_windows.cpp
28-03-2014
It is most like li my changes for: 40 8037226 hotspot compiler/7196199/Test7196199.java fails on 32-bit linux with MaxVectorSize > 16 It explicitly generate SEGV in get_processor_features to verify that YMM registers are correctly restored by signal handler. Looks like Windows signal handler does not work in such case. May be the order of initialization.
28-03-2014
ILW=HMH=>P1 L: Medium, not all arches are affected
28-03-2014