United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6469701 : java.lang.Thread.getStackTrace() causes memory leaks in the VM

Details
Type:
Bug
Submit Date:
2006-09-12
Status:
Closed
Updated Date:
2011-02-16
Project Name:
JDK
Resolved Date:
2009-03-05
Component:
hotspot
OS:
windows_xp
Sub-Component:
svc
CPU:
x86
Priority:
P3
Resolution:
Duplicate
Affected Versions:
5.0
Fixed Versions:
5.0-pool

Related Reports
Duplicate:
Relates:
Relates:

Sub Tasks

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
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
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

CUSTOMER SUBMITTED WORKAROUND :
For the current thread, use java.lang.Throwable.getStackTrace() instead of java.lang.Thread.getStackTrace().
                                     
2006-09-13
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
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

David Holmes has provided this correct resolution.

http://jpsesvr.sfbay.sun.com:8080/ctetools/html/ViewDetail.jsp?index=2799
                                     
2009-01-12



Hardware and Software, Engineered to Work Together