FULL PRODUCT VERSION :
java version "1.5.0_08"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03)
Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode, sharing)
FULL OS VERSION :
Microsoft Windows XP [Version 5.1.2600]
Microsoft Windows [Version 5.2.3790]
A DESCRIPTION OF THE PROBLEM :
Calls to Java-method java.lang.Thread.getStackTrace() leak memory on the native heap, since in the native implementation destructor ThreadStackTrace::~ThreadStackTrace() (in threadService.cpp) frees objects within the GrowableArrays by calling clear_and_deallocate() but does not free the GrowableArray-objects themselves!
This leak seems to be removed in jdk1.6.0-beta2-b86.
We also reported this to Sun support in case# 10898965.
THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Did not try
THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
The leak can be reproduced by the simple program below. When you start it with "java -Xms64m -Xmx64m NativeOOM" Windows TaskManager shows that the virtual memory usage of the process increases very quickly.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
When the VM cannot allocate more memory from the OS (i.e. malloc() returns NULL) the VM terminates and prints a message similar to:
Exception java.lang.OutOfMemoryError: requested 512000 bytes for GrET* in C:/BUILD_AREA/jdk1.5.0_05/hotspot\src\share\vm\utilities\growableArray.cpp. Out of swap space?
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
public class NativeOOM
{
public static void main(String[] args)
{
while (true)
{
Thread.currentThread().getStackTrace();
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Use java.lang.Throwable.getStackTrace() instead of java.lang.Thread.getStackTrace().