JDK-6469701 : java.lang.Thread.getStackTrace() causes memory leaks in the VM
  • Type: Bug
  • Status: Closed
  • Resolution: Duplicate
  • Component: hotspot
  • Sub-Component: svc
  • Priority: P3
  • Affected Version: 5.0
  • OS: windows_xp
  • CPU: x86
  • Submit Date: 2006-09-12
  • Updated Date: 2014-02-27
  • Resolved Date: 2009-03-05
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 Availabitlity Release.

To download the current JDK release, click here.
Other
5.0-poolResolved
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
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().

Comments
SUGGESTED FIX David Holmes has provided this correct resolution. http://jpsesvr.sfbay.sun.com:8080/ctetools/html/ViewDetail.jsp?index=2799
2009-01-12

SUGGESTED FIX Correction, there is no suitable operator delete in ResourceObj in JDK5. The correct fix here is to define ResourceObj::operator delete(void* p) to perform FreeHeap(p) when called on an object that was allocated in the C_Heap. Caution: there may be existing code that calls delete on non-C-heap allocate dobjects. These calls need to be removed.
2008-12-22

SUGGESTED FIX Looking at this again it seems that there is a correct operator delete so the fix should only need to be: + delete _methods; + delete _bcis;
2008-12-19

WORK AROUND CUSTOMER SUBMITTED WORKAROUND : For the current thread, use java.lang.Throwable.getStackTrace() instead of java.lang.Thread.getStackTrace().
2006-09-13

SUGGESTED FIX *** /tmp/geta10923 Wed Sep 13 20:53:43 2006 --- threadService.cpp Wed Sep 13 20:53:38 2006 *************** *** 295,300 **** --- 295,302 ---- ThreadStackTrace::~ThreadStackTrace() { _methods->clear_and_deallocate(); _bcis->clear_and_deallocate(); + ::delete _methods; + ::delete _bcis; }
2006-09-13

WORK AROUND Use Java 6 if possible
2006-09-13

EVALUATION The originator is correct. The GrowableArray objects are not being freed and so a leak is occuring. This does not occur in Java 6 as the means by which stacktraces are put together is quite different.
2006-09-13