JDK-8157548 : JVM crashes sometimes while starting
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 8u91
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-05-23
  • Updated: 2018-07-06
  • Resolved: 2016-09-22
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 Other
8u112Fixed openjdk7uFixed
Related Reports
Duplicate :  
JDK-8162340 - Better class stream parsing
Description
When I start application from command-line it crashes (sometimes!). I attached checkersland.jar

It works fine on the following combinations:

1. (Java 32 bits, no full path to checkersland.jar)
"C:\Program Files (x86)\Java\jre1.8.0_91\bin\java.exe" -jar "checkersland.jar"

2. (Java 32 bits, full path to checkersland.jar)
"C:\Program Files (x86)\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar

3. (Java 64 bits, no full path to checkersland.jar)
"C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar checkersland.jar

BUT!!!
It fails very often when I run (Java 64 bits, full path to checkersland.jar):
"C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar

Output like:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000051b0b7bd, pid=9288, tid=3736
#
# JRE version: Java(TM) SE Runtime Environment (8.0_91-b14) (build 1.8.0_91-b14)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.91-b14 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# V  [jvm.dll+0x7b7bd]
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Pasha\checkersland\output\hs_err_pid9288.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

hs_err_pid9288.log is attached

Environment:
Win 7x64
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)
Comments
Hi Shafi, To fix JDK-8157548: JVM crashes sometimes while starting, there is no need to backport JDK-8162340, which address a much wider set of issues. I mentioned JDK-8162340 in JDK-8157548, just because JDK-8162340 has removed the code that caused JDK-8157548, so JDK-8157548 is no longer applicable to JDK9. For JDK-8157548, the patch is here on systemDictionary.cpp: const char* pkg = "java/"; if (!HAS_PENDING_EXCEPTION && !class_loader.is_null() && parsed_name != NULL && + parsed_name->utf8_length() >= strlen(pkg) && !strncmp((const char*)parsed_name->bytes(), pkg, strlen(pkg))) { // It is illegal to define classes in the "java." package from // JVM_DefineClass or jni_DefineClass unless you're the bootclassloader ResourceMark rm(THREAD); char* name = parsed_name->as_C_string(); char* index = strrchr(name, '/'); + assert(index != NULL, "must be"); *index = '\0'; // chop to just the package name while ((index = strchr(name, '/')) != NULL) { *index = '.'; // replace '/' with '.' in package name } const char* fmt = "Prohibited package name: %s"; size_t len = strlen(fmt) + strlen(name); char* message = NEW_RESOURCE_ARRAY(char, len); jio_snprintf(message, len, fmt, name); Exceptions::_throw_msg(THREAD_AND_LOCATION, vmSymbols::java_lang_SecurityException(), message); } This would avoid calling class_name->as_C_string() twice, so it's a little more efficient than your version below. Also, your patch calls class_name->as_C_string() outside of the ResourceMark, which may cause issues. Thanks - Ioi On 9/14/16 11:25 PM, Shafi Ahmad wrote: Hi Ioi, I just tried to do the backport of https://bugs.openjdk.java.net/browse/JDK-8162340 [http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/53f2e6ca643b] but I am getting many conflicts because of code change of https://bugs.openjdk.java.net/browse/JDK-8140485 [JDK-8140485: Class load and creation cleanup]. So could you please let me know if it is fine to just take below code for the fix of this bug. + const char* javapkg = "java/"; + ResourceMark rm(THREAD); + if (!class_loader.is_null() && + !SystemDictionary::is_platform_class_loader(class_loader) && + class_name != NULL && + strncmp(class_name->as_C_string(), javapkg, strlen(javapkg)) == 0) { i.e. // src/share/vm/classfile/systemDictionary.cpp if (!HAS_PENDING_EXCEPTION && !class_loader.is_null() && parsed_name != NULL && - !strncmp((const char*)parsed_name->bytes(), pkg, strlen(pkg))) { + strncmp(parsed_name->as_C_string(), pkg, strlen(pkg)) == 0) { Regards, Shafi
16-09-2016
Just verified that this bug no longer exists in JDK9. It has been fixed in JDK-8162340 - Better class stream parsing: See http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/53f2e6ca643b -> src/share/vm/oops/instanceKlass.cpp + const char* javapkg = "java/"; + ResourceMark rm(THREAD); + if (!class_loader.is_null() && + !SystemDictionary::is_platform_class_loader(class_loader) && + class_name != NULL && + strncmp(class_name->as_C_string(), javapkg, strlen(javapkg)) == 0) { I am removing JDK9 from the affected version list and removing myself as Assignee. I'll leave the task of fixing JDK8 and previous versions to sustaining team.
09-08-2016
The fix is: + parsed_name->utf8_length() >= strlen(pkg) && !strncmp((const char*)parsed_name->bytes(), pkg, strlen(pkg))) { .... char* index = strrchr(name, '/'); + assert(index != NULL, "must be");
07-08-2016
From the memory dump file, the crash is on this line: const char* pkg = "java/"; if (!HAS_PENDING_EXCEPTION && !class_loader.is_null() && parsed_name != NULL && !strncmp((const char*)parsed_name->bytes(), pkg, strlen(pkg))) { // It is illegal to define classes in the "java." package from // JVM_DefineClass or jni_DefineClass unless you're the bootclassloader ResourceMark rm(THREAD); char* name = parsed_name->as_C_string(); char* index = strrchr(name, '/'); *index = '\0'; // chop to just the package name <<<<<<<<<<<<<<<< CRASH while ((index = strchr(name, '/')) != NULL) { *index = '.'; // replace '/' with '.' in package name } parsed_name looks like this: + SymbolBase {_length=1 _refcount=11 _identity_hash=1839284029 } SymbolBase + _body 0x000000001d74ef38 "java/lang/String��i6/��e" char[1] Note that Symbol::_body is NOT 0-terminated. The class being loaded is "j". parsed_name is dynamically allocated and it, just by chance, occupied the exact same space as a previously freed copy of a Symbol with the content "java/lang/String". So the strncmp reports a match with "java/", but parsed_name->as_C_string() would return a 0-terminated string "j". So strrchr(name, '/') would return NULL.
07-08-2016
I'm speculating because I don't have real data for the crash. We crash while processing the stream which suggests the stream may be corrupt (but no we shouldn't crash even then). I found one "bad" class so it seemed a possible cause. We need to reproduce with classloading logging enabled to try and see exactly what is being done at the time of the crash.
05-08-2016
Even if JVM is trying to load re.class it should write some meaningful message, but not crash.
05-08-2016
In fact re.class contains data, but not java class... This file is not used as a class and therefore shouldn't (???) be loaded. Is it really the root of the problem? Old JREs work fine with that
05-08-2016
On Linux I expanded the jar file and examined each class filer: > for file in *.class ; do > javap -p -c $file > $file.txt > done Error: error while reading constant pool for re.class: unexpected tag at #1: 91 So I wrote a test that just does Class.forName("re") and that resulted in: Exception in thread "main" java.lang.ClassFormatError: Incompatible magic value 2435416082 in class file re at java.lang.ClassLoader.defineClass1(java.base@9-ea/Native Method) in both JDK 9 latest build and JDK 8 GA. So it looks like we have an invalid class that perhaps in some cases can crash the VM.
05-08-2016
The one crash log with symbols shows the crash in SystemDictionary::resolve_from_stream This suggest to me there is some kind of corruption or invalid content in the jar file.
05-08-2016
One user reported me about the problem and I reproduced the issue easily on my PC as well. This problem is not crucial for me, but JVM crash together with regression doesn't look P3 for me.
04-08-2016
Since we can only reproduce this on one machine so far, lowering priority to P3. Still, it's a regression so we should try to fix it.
04-08-2016
I uploaded dump here: https://www.dropbox.com/sh/t2dvmwu8zjqg647/AACp5F8SUl1NfhMcLVdkahw9a?dl=0
17-06-2016
# # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows # I am asking for the above core dump. I think you have to enable for generating it on window. Regarding processor architecture: x86-64 (also known as x64, x86_64 and AMD64), The BSD family of OSs and several Linux distributions use AMD64, and so does Microsoft Windows internally. For more detail you may read https://en.wikipedia.org/wiki/X86-64
08-06-2016
I wonder why I see AMD in logs and env output. In fact I have Intel Core i5... See env.png
07-06-2016
I tried manually many times but couldn't reproduce it. Is it failing with fastdebug build too? If it is failing with fastdebug build could you please upload the core file upload the core file of product build.
07-06-2016
BTW output of your script is: System information: ------------------- Processor Arch: AMD64 OS Name: Microsoft Windows 7 Professional OS Version: 6.1.7601 Service Pack 1 Build 7601 OS Manufacturer: Microsoft Corporation OS Configuration: Member Workstation OS Build Type: Multiprocessor Free BIOS Version: LENOVO JBET50WW (1.15 ), 10.06.2015 Java version: ------------- "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -version java version "1.8.0_91" Java(TM) SE Runtime Environment (build 1.8.0_91-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode) Running Checkersland 20 times: ------------------------------
02-06-2016
Your script works fine on my env as well. Command start /b "Checkersland" "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\temp\checkersland.jar doesn't allow to reproduce the problem. But the problem still exists, I attached screenshot. Just try to run the command several times without "start" command.
02-06-2016
I run this command ""C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar" more than 20 times manually and couldn't reproduce the issue. So thought of running this through below batch file. I run this batch file for 5 times and for me it works fine. Could you please let me know am I missing some thing here? Please note that I am not using checkersland.exe file. I am pasting the output of one run of this batch script. // rum.bat @echo off set loopcount=0 set term=20 echo System information: echo ------------------- echo Processor Arch: %PROCESSOR_ARCHITECTURE% systeminfo | findstr /C:"OS" echo Java version: echo ------------- echo "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -version start /b "" "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -version timeout /t 2 >null echo Running Checkersland %term% times: echo ------------------------------ :loop set /a loopcount=loopcount+1 echo %loopcount%: "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar start /b "Checkersland" "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar timeout /t 10 >null taskkill /f /im java.exe >nul timeout /t 2 >null if %loopcount%==%term% goto exitloop goto loop :exitloop pause // Output of above script "C:\Users\shshahma.ORADEV>run.bat System information: ------------------- Processor Arch: AMD64 OS Name: Microsoft Windows 7 Professional OS Version: 6.1.7601 Service Pack 1 Build 7601 OS Manufacturer: Microsoft Corporation OS Configuration: Member Workstation OS Build Type: Multiprocessor Free System Manufacturer: TOSHIBA BIOS Version: TOSHIBA Version 4.20 , 9/2/2015 Java version: ------------- "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -version java version "1.8.0_91" Java(TM) SE Runtime Environment (build 1.8.0_91-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode) Running Checkersland 20 times: ------------------------------ 1: "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar 2: "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar 3: "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar 4: "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar 5: "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar 6: "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar 7: "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar 8: "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar 9: "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar 10: "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar 11: "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar 12: "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar 13: "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar 14: "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar 15: "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar 16: "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar 17: "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar 18: "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar 19: "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar 20: "C:\Program Files\Java\jre1.8.0_91\bin\java.exe" -jar C:\Pasha\checkersland\output\checkersland.jar Press any key to continue . . . Intentionally I keep jar file same as your path.
02-06-2016
Shafi, please try the reproducer. The first thing to test could be where the regression was introduced
27-05-2016
I can't reproduce the problem with java version "1.8.0_40" Java(TM) SE Runtime Environment (build 1.8.0_40-b27) Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) So, it looks like a regression
24-05-2016
It's perfectly reproducible in command prompt as well. Some user wrote me report that he get the same problem from Total Commander. Did you try to reproduce the problem?
24-05-2016
Hi. Could you try running this on JDK 9 and some earlier versions of JDK 8, like 8u60 and 8 fcs? It would be good to see if this is a recent regression and if it happens in JDK 9 as well. Also, is this reproducable from the "standard" cmd prompt? Some of the paths in the hs_err file contains strange characters, like: C:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u91\6644\hotspot\src\share\vm\prims\j���`X"������? It could be that Far Manager sends command line parameters in an unexpected format perhaps.
24-05-2016
A couple comments: 1. I run java from Far manager x64 2. checkersland.jar doesn't contain any native code, so crashes shouldn't happen 3. the jar file was processed by proguard (version 5.2). Not obfuscated jar runs without crashes.
23-05-2016