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.
There is a memory leak in debugger. Simply restart a project in debugger (SHIFT+F6). I see in profiler that memory usage for each start of debugger is increasing (especially noticeable with instances of o.n.m.debugger.jpda...* classes. See the following screenshots of jprofiler window. Rough estimate is 300kB leaking when you just start and immediately finish the debugger (testing it with jEdit project). If you do some work with the running debugger, the leak gets bigger (see the second screenshot below where the code stopped at a breakpoint and I stepped ti several times before finishing).
Created attachment 14372 [details] Screenshot of jprofiler window with o.n.m.debugger.jpda.* instances after running and finishing debugger for the first time.
Created attachment 14373 [details] Screenshot of jprofiler window with o.n.m.debugger.jpda.* instances after running and finishing the debugger three times.
Created attachment 14374 [details] Screenshot of jprofiler window with o.n.m.debugger.jpda.* instances after running and finishing the debugger four times.
All leaks in debugger fixed, rest of them reported in 44021. *** This issue has been marked as a duplicate of 44021 ***
The leak is still there. Attaching new screenshots of OptimizeIt windows after three invocations of Run / Attach Debugger / OK. The attach action fails but it is enough to see the leak it leaves. Reopening this issue rather than 44021 because it seems to me that this leak is not related to property sheet.
Created attachment 16720 [details] debugger-leak-3-attach-invocations.png
Created attachment 16721 [details] debugger-leak-3-attach-invocations-AttachingSessionProvider.png
Created attachment 16722 [details] debugger-leak-3-attach-invocations-JPDADebuggerImpl.png
Created attachment 16723 [details] debugger-leak-3-attach-invocations-DebuggerOutput.png
I have tried to reproduce it. I have started debugging 50 times, but no memory grow visible. Can you specify how to exactly reproduce it?
The easiest steps to reproduce: 1) Run / Attach debugger... 2) OK 3) Debugger console shows: "Attaching to null Argument unspecified" 4) Right click the Debugger Console and click Close 5) Go To Step 1) and then see the bunch of *debugger* objects in OptimizeIt, left with each invocation...
Aha, but its not very logical usecase. User will probably not start 10 times debugger without selecting some port number. Is it P2?!?
This is not the only usecase. Just the simplest one. Regular debugging also leaks. I am sending you the optimizeit snapshot as promised.
fixed in the main trunk: I have fixed several references QA no impact Checking in api/src/org/netbeans/api/debugger/ActionsManager.java; /cvs/debuggercore/api/src/org/netbeans/api/debugger/ActionsManager.java,v <-- ActionsManager.java new revision: 1.9; previous revision: 1.8 done Checking in ant/antsrc/org/netbeans/modules/debugger/jpda/ant/JPDAStart.java; /cvs/debuggerjpda/ant/antsrc/org/netbeans/modules/debugger/jpda/ant/JPDAStart.java,v <-- JPDAStart.java new revision: 1.29; previous revision: 1.28 done Processing log script arguments... More commits to come... Checking in ui/src/org/netbeans/modules/debugger/jpda/ui/ConnectPanel.java; /cvs/debuggerjpda/ui/src/org/netbeans/modules/debugger/jpda/ui/ConnectPanel.java,v <-- ConnectPanel.java new revision: 1.9; previous revision: 1.8 done Processing log script arguments... More commits to come... Checking in ui/src/org/netbeans/modules/debugger/jpda/ui/breakpoints/Bundle.properties; /cvs/debuggerjpda/ui/src/org/netbeans/modules/debugger/jpda/ui/breakpoints/Bundle.properties,v <-- Bundle.properties new revision: 1.10; previous revision: 1.9 done Checking in ui/src/org/netbeans/modules/debugger/jpda/ui/breakpoints/ExceptionBreakpointPanel.form; /cvs/debuggerjpda/ui/src/org/netbeans/modules/debugger/jpda/ui/breakpoints/ExceptionBreakpointPanel.form,v <-- ExceptionBreakpointPanel.form new revision: 1.4; previous revision: 1.3 done Checking in ui/src/org/netbeans/modules/debugger/jpda/ui/breakpoints/ExceptionBreakpointPanel.java; /cvs/debuggerjpda/ui/src/org/netbeans/modules/debugger/jpda/ui/breakpoints/ExceptionBreakpointPanel.java,v <-- ExceptionBreakpointPanel.java new revision: 1.6; previous revision: 1.5 done
Still seeing some *.debugger.* objects leaking. Will attach more OptimizeIt screenshots to this issue... I have restarted debugger 5 times. First two runs ended up with most of objects cleared (except for e.g. JPDAStart and its listener). The rest three runs left more objects leaked. See the list of instances on the screenshot.
Created attachment 17521 [details] List of leaked instances after 5 runs of debugger
Created attachment 17522 [details] DebuggerOutput instance 1
Created attachment 17524 [details] DebuggerOutput instance 2
Created attachment 17525 [details] JPDAStart instance
When fixed the fix will have to be merged to release40_beta2 branch.
As for the size of the leak - it depends on the configuration of the debugging. Without any breakpoints and watches it is hardly measureable, memory toolbar does not show significant increase. But when measured using jEdit project with 10 breakpoints and 10 watches set, stopping on a breakpoint right at the start of the project, I got the following numbers: jdk 1.5.0-b63, trunk build 0912: after 1st debugger invocation - heap at 30.0MB after 40th debugger invocation - heap at 49.3MB => 495kB per one debugger invocation jdk 1.5.0-b63, q-build 0910: after 1st debugger invocation - heap at 26.7MB after 40th debugger invocation - heap at 46.7MB => 518kB per one debugger invocation I assume that the q-build does not include jjancura's optimizations mentioned above. Thus the difference. Regardless of this, the size of the leak in this debugger configuration (jEdit, 10 breakpoints, 10 watches) is approximately 0.5MB.
usecase with JPDAStart task fixed other pictures looks like as designed for me. you should close all output tabs first to remove all debugger stuff from memory... QA: test debugger start using Step Into action! Index: ant/antsrc/org/netbeans/modules/debugger/jpda/ant/JPDAStart.java =================================================================== RCS file: /cvs/debuggerjpda/ant/antsrc/org/netbeans/modules/debugger/jpda/ant/JPDAStart.java,v retrieving revision 1.29 diff -r1.29 JPDAStart.java 19a20,22 > import java.util.HashSet; > import java.util.Iterator; > import java.util.Set; 80,87d82 < private MethodBreakpoint breakpoint; < < { < DebuggerManager.getDebuggerManager ().addDebuggerListener ( < DebuggerManager.PROP_DEBUGGER_ENGINES, < new Listener () < ); < } 88a84 > 220c216,220 < createBreakpoint (stopClassName); --- > MethodBreakpoint b = createBreakpoint (stopClassName); > DebuggerManager.getDebuggerManager ().addDebuggerListener ( > DebuggerManager.PROP_DEBUGGER_ENGINES, > new Listener (b) > ); 243,244c243,244 < private void createBreakpoint (String stopClassName) { < breakpoint = MethodBreakpoint.create ( --- > private MethodBreakpoint createBreakpoint (String stopClassName) { > MethodBreakpoint breakpoint = MethodBreakpoint.create ( 250,256c250 < } < < private void removeBreakpoint () { < if (breakpoint != null) { < DebuggerManager.getDebuggerManager ().removeBreakpoint (breakpoint); < breakpoint = null; < } --- > return breakpoint; 418c412,421 < private class Listener extends DebuggerManagerAdapter { --- > private static class Listener extends DebuggerManagerAdapter { > > private MethodBreakpoint breakpoint; > private Set debuggers = new HashSet (); > > > Listener (MethodBreakpoint breakpoint) { > this.breakpoint = breakpoint; > } > 427c430,433 < removeBreakpoint (); --- > if (breakpoint != null) { > DebuggerManager.getDebuggerManager ().removeBreakpoint (breakpoint); > breakpoint = null; > } 429a436 > dispose (); 434a442,456 > private void dispose () { > DebuggerManager.getDebuggerManager ().removeDebuggerListener ( > DebuggerManager.PROP_DEBUGGER_ENGINES, > this > ); > Iterator it = debuggers.iterator (); > while (it.hasNext ()) { > JPDADebugger d = (JPDADebugger) it.next (); > d.removePropertyChangeListener ( > JPDADebugger.PROP_STATE, > this > ); > } > } > 442a465 > debuggers.add (debugger); 452a476 > debuggers.remove (debugger);
No, that's not "as designed". When doing repetitive F5 - SHIFT+F5 (restarting debugger) the output window's contents is replaced by new output each time you restart debugger.
Created attachment 17624 [details] DebuggerOutput most probably leaked through listener of WatchesModel
Usecase with watches view opened is fixed now too. Thank you Tonda for your help.
integrated to beta2 branch
Thanks. Will verify in tomorrow's morning beta 2 build.
Verified in Beta 2.