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().