Bugzilla – Full Text Bug Listing
| Summary: | edc - details pane does not display strings greater than 256 regardless of "Max Length…" setting | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Kirk Beitz <kirk.beitz> |
| Component: | cdt-debug-edc | Assignee: | Ken Ryall <ken.ryall> |
| Status: | RESOLVED WONTFIX | QA Contact: | Ken Ryall <ken.ryall> |
| Severity: | major | ||
| Priority: | P3 | CC: | cdtdoug |
| Version: | 7.0.1 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Attachments: | |||
Created attachment 181247 [details] updated patch for edc AbstractStringFormatter + MANIFEST.MF to make use of the "Max Value…" context menu item value as bound for strings displayed in details views updated the patch to use: IPreferenceStore prefs = DsfDebugUITools.getPreferenceStore(); return prefs.getInt(IDebugUIConstants.PREF_MAX_DETAIL_LENGTH); i.e. using DsfDebugUITools eliminates the access restriction necessary in the first patch. also updated the MANIFEST.MF in the patch to show the latest dependencies. other notes pulled from Bug 328191: there are flaws exposed with the use of the "Max Length…" feature for this use: - the dialog states it will treat 0 as unbounded, but AbstractStringFormatter does not interpret it this way; it just skips the read completely. implementing an unbounded read might not be all that difficult, but i'm uncertain that having a completely unbounded read is a good idea. so i'm punting and not implementing it, but not fixing the dialog, either. feedback as to the "community-preferred" alternative is welcome. - by having AbstractStringFormatter#getMaximumLength() return this pref, the pref gets used for the values in the upper portion of the variable view, as well. this may not be desirable for long strings with large user values. - if the user changes the value, it does not take effect for variables in the upper portion of the pane unless the user steps or otherwise causes the value to change, or until the user closes and re-opens the view. - also, when the user changes the value, it does not take effect for variables in the details portion of the view unless the user clicks another value and then comes back to the value of interest … or closes and re-opens the view, or steps to cause the value to change. i'm still inclined to commit this patch to give the user who opened the original report a method for limiting or expanding the strings viewed in the details view, and dealing with the uncovered side-effects after fixing some other higher priority issues. Created attachment 181250 [details]
re-updated patch for edc AbstractStringFormatter + MANIFEST.MF to make use of the "Max Value…" context menu item value as bound for strings displayed in details views
further testing demonstrated (and better self-review would have also shown) that the prefs were being read from one place and written to another, and so the last patch didn't work.
this patch goes back to using DebugUIPlugin for everything, and to the access restriction to get at it from within edc.
(this is part of a batch change) The Eclipse CDT EDC (https://wiki.eclipse.org/CDT/cdt-debug-edc) is now obsolete and has not had any active development since 2011. Therefore the still open bugs are being marked as wontfix. The git repo for the project still exists for posterity at https://git.eclipse.org/c/cdt/org.eclipse.cdt.edc.git/ |
Created attachment 181238 [details] patch for edc AbstractStringFormatter to use the user-entered "Max Value…" as bound for displayed strings customer report: the edc debugger does not respond to the "Max Length…" setting that the user can specify when the Variable view details pane is first opened … the root cause is manifold: a) AbstractStringFormatter#getMaximumLength() is always called to pre-determine the amount of memory to retrieve in order to fill a string b) base level root cause is a hard-coded value of 256 in getMaximumLength() c) once the maximum is retrieved, if the value has bounds, another maximum magic number of 4096 is applied. the attached patch solves the problem at the point of (b) above, in that it makes use of the preferenceStore value provided with the "Max Length…" dialog. this allows (a) to return a enough memory to respond to the user's entry in that dialog to control the size of the string displayed. the maximum value returned by the modified getMaximumLength() is then used instead of 4096 in calculating the upper bound of the bounded-string retrieval.