JDK-8009602 : Should be graceful/informative exit rather than crash
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 7u7
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86
  • Submitted: 2013-03-07
  • Updated: 2013-10-23
  • Resolved: 2013-10-23
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.
Other
hs25Resolved
Related Reports
Duplicate :  
JDK-8007074 - SIGSEGV at ParMarkBitMap::verify_clear()
Description
I'm reporting this on behalf of Vasanth Venkatachalam @ AMD.
He says...

We produced a crash using a simple java ���version and the flags below, with the java process affinitized to a single core.

$JAVA -XX:+PrintGCDetails  -XX:+PrintGCTimeStamps -XX:-UseBiasedLocking -XX:+UseParallelOldGC -Xms12g -Xmx12g -Xmn8g ���version

The system details are:

4P/64C with AMD Opteron��� Processor 6386 SE @ 2.8GhZ
256G of DDR3 RAM
Red Hat Enterprise Linux 6.3

Transparent huge pages was disabled and the value in /proc/sys/vm/nr_hugepages had been manually set to 8000. It turned out the crash was due to this being too low a setting for nr_hugepages. When we either bumped up this value, or enabled transparent huge pages (so that this value doesn���t come into play), the crash went away. So this was a large page configuration issue.

Our question is whether the JVM could not crash and rather exit more gracefully with an error message giving some indocation of the problem.  How much indication, will depend on whether cases such as the above (where the setting for large pages has been misconfigured) can be detected.  At the very least, the JVM shouldn't crash without some message.
Comments
I don't see where we are waiting more info from AMD? This should be easy enough to try and reproduce.
12-08-2013
Need more information from AMD.
09-08-2013
SQE is ok to defer this issue from 7u40
09-07-2013
AMD does not have time to follow up on this.
07-05-2013
Could we get AMD to try to run with a newer build than 7u7? It would be interesting to see if the fix for JDK-7173959 has any impact on their crash. That bug fix is in the hsx24 (JDK7) repository and also in the main hsx repository (JDK8). Due to all the version renumbering it is difficult for me to say which builds to download to be sure to have the fix included. Best is if AMD could build from the latest source and try to run again.
12-03-2013
For ease of reference: Stack: [0x00007fa2de9df000,0x00007fa2deae0000], sp=0x00007fa2deade420, free space=1021k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x30a748] Copy::pd_fill_to_words(HeapWord*, unsigned long, unsigned int)+0x35 V [libjvm.so+0x30a640] Copy::fill_to_words(HeapWord*, unsigned long, unsigned int)+0x3a V [libjvm.so+0xa0f6a4] SpaceMangler::mangle_region(MemRegion)+0xba V [libjvm.so+0x9b5915] PSYoungGen::initialize_work()+0x121 V [libjvm.so+0x9b57ed] PSYoungGen::initialize(ReservedSpace, unsigned long)+0x67 V [libjvm.so+0x2f46f7] AdjoiningGenerations::AdjoiningGenerations(ReservedSpace, unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, unsigned long)+0x68b V [libjvm.so+0x95e15b] ParallelScavengeHeap::initialize()+0x9c3 V [libjvm.so+0xaa7c7f] Universe::initialize_heap()+0x211 V [libjvm.so+0xaa77ab] universe_init()+0x142 V [libjvm.so+0x6a0e65] init_globals()+0x3d V [libjvm.so+0xa8ae3c] Threads::create_vm(JavaVMInitArgs*, bool*)+0x22a V [libjvm.so+0x744225] JNI_CreateJavaVM+0xb0 C [libjli.so+0x337e] JavaMain+0x9e This is an issue with heap configuration so I will re-assign to GC for assessment.
11-03-2013
Here's the reply from Vasanth @ AMD... "I don���t think all those flags should be necessary. Heap settings and affinity should be enough. The affinity does not have to be single core. I used single core affinity to reproduce the problem in the simplest test case. However, I have seen the crash with other affinity configurations." He sent along the hs_err log.. I'll attach it to this bug.
11-03-2013
Did the crash generate a core and/or hs_err log? If a core can we get a stackdump from it? Given it was a large page misconfiguration, are all those flags and the single-core affinity actually needed to reproduce? Thanks.
07-03-2013
Waiting on confirmation of release they created the crash on. Will update the bug report when I get it.
07-03-2013