JDK-4861809 : VM crash when HeapDump requested
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jvmpi
  • Affected Version: 1.4.0,1.4.1,1.4.2
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,solaris_7,solaris_8
  • CPU: x86,sparc
  • Submitted: 2003-05-09
  • Updated: 2003-10-25
  • Resolved: 2003-09-15
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
1.4.2_02 02Fixed
Related Reports
Relates :  
Relates :  
Description

Name: nt126004			Date: 05/09/2003


--------
Mantis: build 1.4.2-rc-b22
Platform: SunOS 5.7
XrunLIB: hprof:heap=all
VM: -server
VM_ARG: [ -Xint | -Xmixed | -Xcomp ]
Appl: SwingSet2
--------

Requesting heapdumps (ctrl-\) while running the SwingSet2 demo with the -Xrunhprof:heap=all library; the VM will core dump.

Here is the command line that I entered: 

"java -jar -server -Xint -Xrunhprof:heap=all $JAVA_HOME/demo/jfc/SwingSet2/SwingSet2.jar" 

Then start taking heap dumps (ctrl+\) immediately. From my testing, the VM crash will usually happen during the startup of the SwingSet2 app (sometimes before the SwingSet Splash screen is displayed).

Alternatively, you can also try substituting the '-Xint' with '-Xcomp' as well.

The occurance of this issue can be somewhat sporatic, but consistant enough log this bug.

Below is the output from the VM crash.

--------
Unexpected Signal : 10 occurred at PC=0xFE45F020
Function=[Unknown. Nearest: JVM_RaiseSignal+0x3EC34]
Library=/workroom/jsdk/solaris_sparc/sun/1.4.2/prerelease/jdk1.4.2_b22/jre/lib/sparc/server/libjvm.so


Dynamic libraries:
0x10000 	java
0xff350000 	/usr/lib/libthread.so.1
0xff390000 	/usr/lib/libdl.so.1
0xff200000 	/usr/lib/libc.so.1
0xff330000 	/usr/platform/SUNW,Ultra-60/lib/libc_psr.so.1
0xfe000000 	/workroom/jsdk/solaris_sparc/sun/1.4.2/prerelease/jdk1.4.2_b22/jre/lib/sparc/server/libjvm.so
0xff2d0000 	/usr/lib/libCrun.so.1
0xff1e0000 	/usr/lib/libsocket.so.1
0xff100000 	/usr/lib/libnsl.so.1
0xff0d0000 	/usr/lib/libm.so.1
0xff0b0000 	/usr/lib/libsched.so.1
0xff300000 	/usr/lib/libw.so.1
0xff090000 	/usr/lib/libmp.so.2
0xff060000 	/workroom/jsdk/solaris_sparc/sun/1.4.2/prerelease/jdk1.4.2_b22/jre/lib/sparc/native_threads/libhpi.so
0xfe7d0000 	/workroom/jsdk/solaris_sparc/sun/1.4.2/prerelease/jdk1.4.2_b22/jre/lib/sparc/libverify.so
0xfe790000 	/workroom/jsdk/solaris_sparc/sun/1.4.2/prerelease/jdk1.4.2_b22/jre/lib/sparc/libjava.so
0xff020000 	/workroom/jsdk/solaris_sparc/sun/1.4.2/prerelease/jdk1.4.2_b22/jre/lib/sparc/libzip.so
0xfdfa0000 	/workroom/jsdk/solaris_sparc/sun/1.4.2/prerelease/jdk1.4.2_b22/jre/lib/sparc/libhprof.so
0xf0c80000 	/workroom/jsdk/solaris_sparc/sun/1.4.2/prerelease/jdk1.4.2_b22/jre/lib/sparc/libawt.so
0xfdd80000 	/workroom/jsdk/solaris_sparc/sun/1.4.2/prerelease/jdk1.4.2_b22/jre/lib/sparc/libmlib_image.so
0xfc190000 	/workroom/jsdk/solaris_sparc/sun/1.4.2/prerelease/jdk1.4.2_b22/jre/lib/sparc/motif21/libmawt.so
0xf0a00000 	/usr/dt/lib/libXm.so.4
0xfb890000 	/usr/openwin/lib/libXt.so.4
0xfc3d0000 	/usr/openwin/lib/libXext.so.0
0xfde90000 	/usr/openwin/lib/libXtst.so.1
0xf0900000 	/usr/openwin/lib/libX11.so.4
0xfc2a0000 	/usr/openwin/lib/libdps.so.5
0xfc3a0000 	/usr/openwin/lib/libSM.so.6
0xfbbd0000 	/usr/openwin/lib/libICE.so.6
0xfbba0000 	/usr/openwin/lib/libdga.so.1
0xf0800000 	/workroom/jsdk/solaris_sparc/sun/1.4.2/prerelease/jdk1.4.2_b22/jre/lib/sparc/libfontmanager.so
0xfbab0000 	/workroom/jsdk/solaris_sparc/sun/1.4.2/prerelease/jdk1.4.2_b22/jre/lib/sparc/libjpeg.so

Heap at VM Abort:
Heap
 def new generation   total 2112K, used 2112K [0xf1400000, 0xf1620000, 0xf2950000)
  eden space 2048K, 100% used [0xf1400000, 0xf1600000, 0xf1600000)
  from space 64K, 100% used [0xf1600000, 0xf1610000, 0xf1610000)
  to   space 64K,   0% used [0xf1610000, 0xf1610000, 0xf1620000)
 tenured generation   total 1408K, used 1359K [0xf2950000, 0xf2ab0000, 0xf5400000)
   the space 1408K,  96% used [0xf2950000, 0xf2aa3fd0, 0xf2aa4000, 0xf2ab0000)
 compacting perm gen  total 16384K, used 3823K [0xf5400000, 0xf6400000, 0xf9400000)
   the space 16384K,  23% used [0xf5400000, 0xf57bbe08, 0xf57bc000, 0xf6400000)

Local Time = Thu May  8 13:02:15 2003
Elapsed Time = 32
#
# HotSpot Virtual Machine Error : 10
# Error ID : 4F530E43505002EF 01
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Server VM (1.4.2-rc-b22 interpreted mode)
#
(Review ID: 185452) 
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_02 tiger-beta FIXED IN: 1.4.2_02 tiger-beta INTEGRATED IN: 1.4.2_02 tiger-b28 tiger-beta
14-06-2004

PUBLIC COMMENTS .
10-06-2004

SUGGESTED FIX ------- jvmpi.cpp ------- *** /tmp/sccs.yyaWXy Fri Jul 11 12:24:55 2003 --- jvmpi.cpp Fri Jul 11 12:13:19 2003 *************** *** 1909,1915 **** ~RootElementForFrame() { if (_roots != NULL) { _roots->clear_and_deallocate(); ! delete _roots; } if (_jni_local_roots != NULL) { _jni_local_roots->clear_and_deallocate(); --- 1909,1915 ---- ~RootElementForFrame() { if (_roots != NULL) { _roots->clear_and_deallocate(); ! FreeHeap(_roots); } if (_jni_local_roots != NULL) { _jni_local_roots->clear_and_deallocate(); *************** *** 1937,1943 **** } void add_root(oop obj) { if (_roots == NULL) { ! _roots = new GrowableArray<oop>(INIT_ROOTS_ARRAY_SIZE, true); } _roots->append(obj); } --- 1937,1943 ---- } void add_root(oop obj) { if (_roots == NULL) { ! _roots = new (ResourceObj::C_HEAP) GrowableArray<oop>(INIT_ROOTS_ARRAY_SIZE, true); } _roots->append(obj); } ###@###.### 2003-07-11
11-07-2003

EVALUATION commit this bug to 1.4.2_02 ###@###.### 2003-06-06 this problem seems to be in RootElementForFrame::add_root allocate _roots array in resource area (although the data of the array in c heap). this add_root is called by some oops_do so i guess the sometimes the memory is freed after the call is returned. i havent figured out which oops_do actually free it but i think the safe way is to allocate it on heap. ###@###.### 2003-07-11
11-07-2003