Community
Participate
Working Groups
Build Identifier: M20100909-0800 It seems that the GDB Traces console just keeps growing when more stuff is added to it. It might be a good idea to limit its growth to some reasonable (configurable?) size, perhaps in a circular way, where the oldest info is discarded when the console gets full. Reproducible: Always Steps to Reproduce: 0. Clear the GDB Traces console, type something you will recognize. 1. Do something that generates a lot of output on the GDB Traces console 2. repeat step 1 many times 3. scroll up the console and check that what you typed in step 0 is still at the top of the console
Created attachment 188111 [details] Suggested fix Here is what I suggest as a fix. I've added a preference to Preferences->C/C++->Debug->GDB which says "Limit GDB traces output (# lines):" And I've set the default to 5000 lines. What is not so nice is that the IOConsole class that I use does not deal with lines but with characters. Therefore, having a limit of x lines is only an approximation because I have to convert it to a number of characters. For the conversion, since I know each line is at most 100 characters, I've assumed the worst and set the limit to 100*maxLines characters. What this means in practice is that if the user set the maxLines to 100 the console will accept 100*100 characters, which will on average amount to more than 100 lines since the lines can only be shorter than the worst case of 100. I personally think this is fine since this console is meant mostly for debugging and having more data is better than less. If the user finds that there is still too much output, she can reduce the maxLines even more. Any comments?
Created attachment 188112 [details] Suggested fix with proper @since tags Just added some missing @since tags and copyright dates.
Created attachment 188255 [details] Fix for HEAD On second thought, asking for a limit in lines which will very loosely be respected (we could end up with up to 100 times more lines than the limit) seems like a bad idea. I changed the limit to use characters since that is what the IOConsole code requires. It is not as user friendly, but I least it will be correct. Since this console is more for debugging, I'm not too worried about this. Committed to HEAD.
Created attachment 188266 [details] Fix for 7_0 The fix for 7_0 cannot add the new preference but I think the 'leak' of memory is important, so here is a one-liner fix for 7_0 which hardcodes a limit of 500000 characters. Committed to 7_0
Fixed. Sergey, since you recently change the DSF-GDB preferences, this code will make sense to you. Can you review?
Few questions/suggestions: TracingConsoleManager.java -------------------------- 1. The purpose of fMaxNumCharacters and fMinNumCharacters is not clear to me. Should the value of PREF_MAX_GDB_TRACES preference be used instead of hardcoded fMaxNumCharacters? Should fMinNumCharacters be replaced by a certain percentage of the value of the value of PREF_MAX_GDB_TRACES preference? 2. Although the maximum capacity of the console is expressed in characters, the truncation should always remove complete lines. MessagesForPreferences.properties --------------------------------- In GdbDebugPreferencePage_maxGdbTraces_label for replace "# characters" with "number of characters".
(In reply to comment #6) > Few questions/suggestions: > > TracingConsoleManager.java > -------------------------- > 1. The purpose of fMaxNumCharacters and fMinNumCharacters is not clear to me. fMax/fMin... correspond to the HighWaterMark/LowWaterMark parameters as used by IOConsole.setWaterMarks() > Should the value of PREF_MAX_GDB_TRACES preference be used instead of > hardcoded fMaxNumCharacters? The hard-coding when I declared the variables was for extra safety, but if you look in the constructor, I call setWaterMarks() with the value of PREF_MAX_GDB_TRACES. > Should fMinNumCharacters be replaced by a certain percentage > of the value of the value of PREF_MAX_GDB_TRACES preference? That would be another approach. What is important is the value of (fMaxNumCharacters-fMinNumCharacters) which is how many characters will be deleted from the console when it gets too full. The algo I chose sets fMinNumCharacters so that 100,000 chars will be deleted. This seemed more than enough when looking at the rate at which GDB traces are printed. Is this ok with you? > 2. Although the maximum capacity of the console is expressed in characters, the > truncation should always remove complete lines. I just re-use the lowWaterMark and HighWaterMark feature of the IOConsole, which TracingConsole extends, so I don't have control over how the truncation is done. > MessagesForPreferences.properties > --------------------------------- > In GdbDebugPreferencePage_maxGdbTraces_label for replace "# characters" with > "number of characters". I copied this from the build console preference, in an attempt to be consistent: "Limit console output (# lines):" are you ok with keeping it like that?
(In reply to comment #6) > Few questions/suggestions: BTW, thanks for the quick review!
(In reply to comment #7) > What is important is the value of (fMaxNumCharacters-fMinNumCharacters) which > is how many characters will be deleted from the console when it gets too full. Would it be better to define a constant for that value explicitly? > I copied this from the build console preference, in an attempt to be > consistent: > "Limit console output (# lines):" > > are you ok with keeping it like that? So the build console supports truncation of whole lines. Is there a way to reuse/copy that code? I would definitely prefer "number of" to "#" for both the build and the gdb trace consoles.
(In reply to comment #9) > (In reply to comment #7) > > What is important is the value of (fMaxNumCharacters-fMinNumCharacters) which > > is how many characters will be deleted from the console when it gets too full. > > Would it be better to define a constant for that value explicitly? I'll do that. > > I copied this from the build console preference, in an attempt to be > > consistent: > > "Limit console output (# lines):" > > > > are you ok with keeping it like that? > > So the build console supports truncation of whole lines. Is there a way to > reuse/copy that code? I don't use the same console as the build console. The IOConsole is contributed by the platform and works with characters. We could have our own mechanism of deleting whole lines, but that would be some effort that I'm not sure is justified (for me at least :-)) > I would definitely prefer "number of" to "#" for both the build and the gdb > trace consoles. Ok, I'll do that. I'll probably get it done first thing next week though. Thanks for the comments.
(In reply to comment #10) > I don't use the same console as the build console. The IOConsole is > contributed by the platform and works with characters. We could have our own > mechanism of deleting whole lines, but that would be some effort that I'm not > sure is justified (for me at least :-)) Agree. Maybe we should file an enhancement request against IOConsole to make it support truncation at line boundaries.
Created attachment 188443 [details] Fixes based on Sergey's comments The patch addresses Sergey's comments and has been checked in to HEAD. I also added a listener to the preference to enable/disable GDB traces, so that when GDB traces are disabled, the limit of characters option becomes grayed out. (In reply to comment #9) > (In reply to comment #7) > > What is important is the value of (fMaxNumCharacters-fMinNumCharacters) which > > is how many characters will be deleted from the console when it gets too full. > > Would it be better to define a constant for that value explicitly? Done, inside TraceControlManager. > I would definitely prefer "number of" to "#" for both the build and the gdb > trace consoles. Done. And I filed Bug 336513 for the build console wording.
BTW, both comments were about maintainability and the UI, which are both not applicable to the 7_0 branch (won't be maintained and no preference added).
*** cdt cvs genie on behalf of mkhouzam *** Bug 335895: GDB Traces Console has infinite capacity [*] TracingConsoleManager.java 1.5 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/console/TracingConsoleManager.java?root=Tools_Project&r1=1.4&r2=1.5 [*] GdbDebugPreferencePage.java 1.9 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/preferences/GdbDebugPreferencePage.java?root=Tools_Project&r1=1.8&r2=1.9 [*] MessagesForPreferences.properties 1.5 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/preferences/MessagesForPreferences.properties?root=Tools_Project&r1=1.4&r2=1.5 [*] IGdbDebugPreferenceConstants.java 1.6 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/IGdbDebugPreferenceConstants.java?root=Tools_Project&r1=1.5&r2=1.6 [*] TracingConsoleManager.java 1.4 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/console/TracingConsoleManager.java?root=Tools_Project&r1=1.3&r2=1.4 [*] GdbPreferenceInitializer.java 1.6 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/preferences/GdbPreferenceInitializer.java?root=Tools_Project&r1=1.5&r2=1.6 [*] MessagesForPreferences.java 1.7 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/preferences/MessagesForPreferences.java?root=Tools_Project&r1=1.6&r2=1.7 [*] GdbDebugPreferencePage.java 1.8 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/preferences/GdbDebugPreferencePage.java?root=Tools_Project&r1=1.7&r2=1.8 [*] MessagesForPreferences.properties 1.4 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/preferences/MessagesForPreferences.properties?root=Tools_Project&r1=1.3&r2=1.4
*** cdt cvs genie on behalf of mkhouzam *** Bug 335895: GDB Traces Console has infinite capacity [*] TracingConsoleManager.java 1.1.2.1 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/console/TracingConsoleManager.java?root=Tools_Project&r1=1.1&r2=1.1.2.1
*** cdt cvs genie on behalf of mkhouzam *** Bug 335895: GDB Traces Console has infinite capacity [*] TracingConsoleManager.java 1.5 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/console/TracingConsoleManager.java?root=Tools_Project&r1=1.4&r2=1.5 [*] GdbDebugPreferencePage.java 1.9 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/preferences/GdbDebugPreferencePage.java?root=Tools_Project&r1=1.8&r2=1.9 [*] MessagesForPreferences.properties 1.5 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/preferences/MessagesForPreferences.properties?root=Tools_Project&r1=1.4&r2=1.5
