Refer to Incident Manager Report #192240

After requesting a number of dumps (sending a SIGQUIT to HPROF when running with 'heap=all' parameter), the process' memory usage slowly increases and never levels off.

The same effect can be observed using a simple JVMPI client that only
requests a heap dump (does no processing with the dump at all), so it
appears to be a leak in the JVM.


Environment:

Tested on: RedHat 7.3 (x86), Win2K, Solaris
Tested with: 1.3.1_02, 1.3.1_08
Unable to observe the problem with 1.4.0, 1.4.1, 1.4.2 VMs


How to repeat:

1) Run an application with hprof (the example below is for Tomcat 4.0.x):

java -hprof:heap=all -classpath $CATALINA_HOME/bin/bootstrap.jar -Dcatalina.home=$CATALINA_HOME -Dcatalina.base=$CATALINA_HOME org.apache.catalina.startup.Bootstrap start

2) Let the VM settle -- a server application like Tomcat will eventually
get to the point that it sits idle.

3) Send the process a SIGQUIT every 30 seconds or so.

4) Observe the JVM process size (using 'top' or similar).
----

###@###.###
I'd just like to make it clear that the observed leak was in the JVM
(though there may be one in HPROF as well). The JVMPI client we tested
with did not allocate any memory.

Using HPROF should allow you to easily reproduce the problem since it
responds to SIGQUIT to generate a heap dump.


###@###.###
An update wrt. the 1.3.1_09-b02 binaries: I've tested it and the
problem is still there.

Suggestions for reproducing the problem on Windows:

You could try using cygwin (it might come with a kill command), or you
can hit ctrl-break (which HPROF listens for to generate a heap dump --
refer to HPROF docs for details). You should start noticing a gradual
increase in the process size after only a few heap dumps; you should
only have to wait a few seconds for the dump to complete (after which
you can request another).

Note that you won't see any leak if no heap dumps are requested.