This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 68098 - Memory leak with each debugger restart
Summary: Memory leak with each debugger restart
Status: VERIFIED FIXED
Alias: None
Product: debugger
Classification: Unclassified
Component: Java (show other bugs)
Version: 5.x
Hardware: All All
: P3 blocker (vote)
Assignee: Martin Entlicher
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2005-11-04 13:58 UTC by Antonin Nebuzelsky
Modified: 2005-11-14 16:29 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
List of leaking instances from the debugger packages (24.67 KB, text/html)
2005-11-04 13:59 UTC, Antonin Nebuzelsky
Details
Reference graph of the older Session instance (90.92 KB, image/png)
2005-11-04 14:00 UTC, Antonin Nebuzelsky
Details
Reference graph of the newer Session instance (88.42 KB, image/png)
2005-11-04 14:00 UTC, Antonin Nebuzelsky
Details
Reference graph of the older JPDADebuggerImpl instance (95.60 KB, image/png)
2005-11-04 14:01 UTC, Antonin Nebuzelsky
Details
Reference graph of the newer JPDADebuggerImpl instance (94.47 KB, image/png)
2005-11-04 14:02 UTC, Antonin Nebuzelsky
Details
List of temporarily leaking instances from the debugger packages (24.21 KB, image/png)
2005-11-09 22:24 UTC, Antonin Nebuzelsky
Details
List of temporarily leaking instances from the debugger packages (24.21 KB, text/html)
2005-11-09 22:24 UTC, Antonin Nebuzelsky
Details
OptimizeIt screenshot (91.93 KB, image/png)
2005-11-09 22:25 UTC, Antonin Nebuzelsky
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Antonin Nebuzelsky 2005-11-04 13:58:39 UTC
Each start-finish of debugger leaves a memory leak. See the attached list of
debugger objects which have accumulated after 2 restarts of debugger on jEdit
project. I will also attach reference chains for Session and JPDADebuggerImpl
instances, both from the first run of the debugger and from the second run of
the debugger (the reference chains in these cases differ).
Comment 1 Antonin Nebuzelsky 2005-11-04 13:59:25 UTC
Created attachment 26626 [details]
List of leaking instances from the debugger packages
Comment 2 Antonin Nebuzelsky 2005-11-04 14:00:15 UTC
Created attachment 26627 [details]
Reference graph of the older Session instance
Comment 3 Antonin Nebuzelsky 2005-11-04 14:00:54 UTC
Created attachment 26628 [details]
Reference graph of the newer Session instance
Comment 4 Antonin Nebuzelsky 2005-11-04 14:01:40 UTC
Created attachment 26629 [details]
Reference graph of the older JPDADebuggerImpl instance
Comment 5 Antonin Nebuzelsky 2005-11-04 14:02:19 UTC
Created attachment 26630 [details]
Reference graph of the newer JPDADebuggerImpl instance
Comment 6 Antonin Nebuzelsky 2005-11-04 14:02:55 UTC
Martine, let me know if I can give you more information from the profiler...
Comment 7 Martin Entlicher 2005-11-08 13:38:15 UTC
This seems to be a regression caused by the map that stores actions which are to
be disabled in toolbar when an action is running.
Comment 8 Martin Entlicher 2005-11-08 14:17:29 UTC
I've identified two problems: a HashMap in JPDADebuggerActionProvider and
lastDebugger field in EvaluateAction.
Both use weak references now:

/cvs/debuggerjpda/ui/src/org/netbeans/modules/debugger/jpda/ui/actions/EvaluateAction.java,v
 <--  EvaluateAction.java
new revision: 1.4; previous revision: 1.3

/cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/actions/JPDADebuggerActionProvider.java,v
 <--  JPDADebuggerActionProvider.java
new revision: 1.10; previous revision: 1.9

The mem. leak should not occur now, please verify.
Comment 9 Antonin Nebuzelsky 2005-11-09 22:22:38 UTC
The accumulating leak is gone. However there is still temporary leak (until
another instance of JPDA debugger is run). As you can see at the OptimizeIt
screenshots I'll attach, the reference path keeping all the stuff in memory is
JPDADebuggerImpl <- IOManager <- DebuggerOutput (a static variable). This should
be fixed as well because if the user does not run debugger any more, the objects
are kept in memory.
Comment 10 Antonin Nebuzelsky 2005-11-09 22:24:14 UTC
Created attachment 26802 [details]
List of temporarily leaking instances from the debugger packages
Comment 11 Antonin Nebuzelsky 2005-11-09 22:24:16 UTC
Created attachment 26803 [details]
List of temporarily leaking instances from the debugger packages
Comment 12 Antonin Nebuzelsky 2005-11-09 22:25:45 UTC
Created attachment 26804 [details]
OptimizeIt screenshot
Comment 13 Martin Entlicher 2005-11-11 16:26:59 UTC
The DebuggerOutput is holding a set of IOManagers. This is because it will close
the old Debugger Console window when a new session is started. The Debugger
Console stays opened even after the debugger finishes - for information purposes.

IMHO the correct fix here is to hold the JPDADebugger instance weakly in
IOManager, so that it can be released after the debugger session has finished.
Comment 14 Martin Entlicher 2005-11-11 16:34:41 UTC
Things were much easier at the end, the debugger field in IOManager was not used
at all. Therefore I've removed it and it should hopefully finally solve the mem.
leak problem:

/cvs/debuggerjpda/ui/src/org/netbeans/modules/debugger/jpda/ui/DebuggerOutput.java,v
 <--  DebuggerOutput.java
new revision: 1.27; previous revision: 1.26

/cvs/debuggerjpda/ui/src/org/netbeans/modules/debugger/jpda/ui/IOManager.java,v
 <--  IOManager.java
new revision: 1.16; previous revision: 1.15
Comment 15 Antonin Nebuzelsky 2005-11-14 16:29:48 UTC
Verified. Thanks.