JDK-4507533 : HPROF: No heap dump generated (java.exe crashes or HPROF ERROR: heap dump size < 0)
  • Type: Bug
  • Component: tools
  • Sub-Component: hprof
  • Affected Version: 1.4.0,1.4.1,1.4.2
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic,solaris_8
  • CPU: x86,sparc
  • Submitted: 2001-09-26
  • Updated: 2005-03-11
  • Resolved: 2005-03-11
Related Reports
Relates :  
JDK-4491764 - JVMPI method entry, exit events cause client VM to crash with Unexpected Signal.
Relates :  
JDK-4489387 - -Xrunhprof crashed jvm or got program run to hang
Relates :  
JDK-4861809 - VM crash when HeapDump requested
Description
To reproduce:
java -Xrunhprof:heap=all -jar SwingSet2.jar

Error got:
HPROF ERROR: heap dump size < 0

This is an intermittent error.  Sometimes I also got the error when running
hprof on Jmol application too or using -Xrunhprof:heap=dump too.

See 4489387 and 4491764 for related info.

This heap dump problem occurs on all platforms.


-------------------------------------------
updated 09/19/02 ###@###.###

I ran the below command using J2SE 1.4.1-b21 on win2k and once the application starts loading, initiate heap dumps through CTRL-BREAK.

$ /cygdrive/d/tmp/j2sdk1.4.1/bin/java -showversion -jar  -Xrunhprof:heap=all ./SwingSet2.jar

Try to take consecutive heap dumps (CTRL+BREAK) when the SwingSet2 demo is starting up and you  will get the java.exe crash error. Licensee first discovered issue when taking heap snapshots in MemoryDebugger while the 
application being profiled was still being loaded. Dr Watson logs a java.exe crash when testing for this same functionality under -Xrunhprof:heap=all.

Customer says this issue seems to have started around build 1.4.1-rc-b20. It exists in 1.4.1-rc-b21 as well. They did not get java.exe crash error under 1.4.1-rc-b18.
Comments
WORK AROUND Try using the 1.5.0 version of hprof. ###@###.### 2005-03-11 19:56:28 GMT
11-03-2005
EVALUATION ###@###.### 2002-11-22 (updated 2002-11-25) This bug also reproduces with "java -Xrunhprof:heap=all PepTest". For this failure, class java.util.Random is reported with particular jobjectID in a CLASS_LOAD event. During a GC, a new jobjectID is reported in an OBJ_MOVE event. When a HEAP_DUMP event is requested, an unexpected jobjectID is reported for class java.util.Random. Something has changed the jobjectID associated with java.util Random after the OBJ_MOVE event and before the HEAP_DUMP event. My guess is that we have somehow missed a GC related relocation. ###@###.### 2002-11-25 The hprof agent JVM_SHUT_DOWN event handler has a race in it. It disables all JVM/PI events before doing the final HEAP_DUMP request. If a class is relocated after the OBJ_MOVE event has been disabled, but before the HEAP_DUMP event is processed, then a unknown jobjectID will be present in the HEAP_DUMP data. I think the code that caused the -1 return value is also suspect: case HPROF_GC_CLASS_DUMP: { int n; int i; jobjectID class_id = hprof_dump_read_id(); hprof_class_t *class = hprof_lookup_class(class_id); if (class == NULL) { return -1; } This particular code block assumes that the class_id value is known prior to handling the HEAP_DUMP event. If the agent was "disabled" during the class's CLASS_LOAD event and no other event has referred to the class before the HEAP_DUMP event, then this class_id value might be legitimately "unknown" at this time. Granted that this is very much a corner case, but the assumption still bothers me. ----- Closing this out as "will not fix". The hprof in 1.5 is completely different and the experimental JVMPI interface that this 1.4.1 hprof is based on is being removed in 1.6. ###@###.### 2005-03-11 19:56:27 GMT
11-03-2005