JDK-6892275 : java is core dumping with osol_1002-124 out of swap space
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: osol_2009.06
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: open_solaris
  • CPU: x86,sparc
  • Submitted: 2009-10-16
  • Updated: 2013-09-12
  • Resolved: 2011-01-03
Related Reports
Duplicate :  
JDK-6302804 - Hotspot VM dies ungraceful death when C heap is exhausted in various places.
Duplicate :  
JDK-6896673 - java is core dumping with osol_1002-124 assert("offset table expansion") out of C heap
Description
java is core dumping on osol_1002-124.
The core dump can be accessed via NFS at:
/net/irperf.ireland/export/work/core_images/Thu.Oct.15.2009.oaf603.volano_server_tuned.osol_1002-124

Release Info:

                       OpenSolaris Development snv_124 X86
            Copyright 2009 Sun Microsystems, Inc.  All Rights Reserved.
                         Use is subject to license terms.
                            Assembled 25 September 2009


pstack output:

core 'core.java.1045.1255635662' of 1045:	/usr/bin/java -server -Xms1600m -Xmx1600m -XX:+AggressiveHeap COM.vola
-----------------  lwp# 1  --------------------------------
 feea1ff7 ???????? (2, 80470c4, 0, fee995f7, 8052260, 80479d8)
 fee9964c ???????? (2, 0, 8047130, 1, 8047134, 806a8ac)
 fee9979b ???????? (2, 0, 8047130)
 08058ae7 ContinueInNewThread (8052260, 50000, 0, 80479d8, 8047990) + 4f
 08051f59 main     (0, 806b064, 8047a70) + aa1
 0805142a _start   (6, 8047b6c, 8047b7a, 8047b82, 8047b8c, 8047b96) + 7a
-----------------  lwp# 2  --------------------------------
 feea1fc7 ???????? ()


I've added the hs_err_pid* file to the core files.
Comments
EVALUATION This is a duplicate of 6302804, which changes the error message to be more helpful when the VM cannot continue because the system is out of swap space.
03-01-2011
EVALUATION I think the only way to handle these bugs is to have another version of hs_err_pid file that is a bit clearer about running out of swap space and doesn't look like Hotspot has encountered an internal error. We could add native memory tracking to the output when that is implemented. That would be really useful. Not sure what we want in the OONM (out of native memory) dump file that we already print in the hs_err_pid* file. Is VM stack trace where we got OONM useful? I guess it could be. At least the location where the OONM was encountered would be added. I think that would be enough. What's in registers and signal information is not important. I'll propose a new format.
30-11-2010