JDK-7125594 : C-heap growth issue in ThreadService::find_deadlocks_at_safepoint
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-12-28
  • Updated: 2013-09-12
  • Resolved: 2012-03-29
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 Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 JDK 8 Other
6u31-revFixed 7u4Fixed 8Fixed hs20.6Fixed
Related Reports
Relates :  
JDK-7066129 - GarbageCollectorMXBean#getLastGcInfo leaks native memory
Description
In the process of debugging 7066129  the customer found another user who is also seeing C-heap growth. 

They have narrowed it down to ThreadService::find_deadlocks_at_safepoint
 
  
> gdb) info leak 4
> 240 bytes leaked in 10 blocks (0.68% of all bytes leaked)
> These range in size from 24 to 24 bytes and are allocated
> #0  0x9fffffff7e944fa2 in os::malloc(unsigned long)   at
> /wsp/jinteg/SVN/jinteg_h6.0.13.rc1b1/hotspot/src/share/vm/runtime/os.cpp:793
> #1  0x9fffffff7cff5a22 in CHeapObj::operator new(unsigned long)   at
> /wsp/jinteg/SVN/jinteg_h6.0.13.rc1b1/hotspot/src/share/vm/memory/allo
> cation.cpp:50
> #2  0x9fffffff7ed95a
> <http://ukpatch.uksr.hp.com:32080/search/patch?patch=ff7ed95a>32 in
> ThreadService::find_deadlocks_at_safepoint(bool)   at
> /wsp/jinteg/SVN/jinteg_h6.0.13.rc1b1/hotspot/src/share/vm/
> services/threadService.cpp:306
> #3  0x9fffffff7ee7f822 in VM_FindDeadlocks::doit()
See comments for the testcase.
Comments
EVALUATION http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8a63c6323842
22-03-2012
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8a63c6323842
07-01-2012
SUGGESTED FIX The ThreadService::find_deadlocks_at_safepoint method leaks on DeadlockCycle object every time it is called. A DeadlockCycle object, referenced by the 'cycle' local variable, is pre-allocated and used to store blocked threads. If a deadlock is found, 'cycle' is added to the deadlock list (referenced by the 'deadlocks' local variable) and a new DeadlockCycle object is created and re-assign to the 'cycle' variable. Once all the threads have been processed, the deadlock list is returned, or NULL if no deadlock has been found. In both case, the last DeadlockCycle object that has been allocated, still referenced by 'cycle', is not returned to caller method nor deallocated, causing the memory leak. The fix is to call delete on the object pointed by 'cycle' before returning the result.
06-01-2012
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8a63c6323842
05-01-2012
PUBLIC COMMENTS Testcase: import java.lang.management.*; import java.io.*; import java.lang.*; import java.util.*; class TESTleak { static void checkit(){ try { while (1 ==1 ){ ThreadMXBean tmx = ManagementFactory.getThreadMXBean(); long[] ids = tmx.findDeadlockedThreads(); if (ids != null) { System.out.println("The following threads are deadlocked:"); } Thread.sleep(1000); } } catch (Exception e) { System.out.println("Got Exception.."); } } public static void main( String Args[]){ checkit(); } }
29-12-2011