| Summary: | [Memory Browser] view doesn't persist list of memory tabs in launch configuration | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Norman Yee <normankyee> |
| Component: | cdt-memory | Assignee: | cdt-debug-inbox <cdt-debug-inbox> |
| Status: | NEW --- | QA Contact: | Jonah Graham <jonah> |
| Severity: | normal | ||
| Priority: | P3 | CC: | cdtdoug, jonah, marc.khouzam, Randy.Rohrbach, tracy |
| Version: | 7.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| See Also: |
https://git.eclipse.org/r/84694 https://git.eclipse.org/r/#/c/84694/ |
||
| Whiteboard: | |||
| Attachments: | |||
|
Description
Norman Yee
Created attachment 190309 [details] Patch for this bug plus a small change to my fix for Bug 338545 Created attachment 190556 [details] Updated patch because of a fix I made to Bug 338545. Created attachment 190557 [details] Updated patch because of a fix I made to Bug 338545 Created attachment 190595 [details]
Modified previous patch to compile and work.
Norman
I tried this patch without success. First of all there were
compilation errors because your Java compiler is 1.6 based.
So things like
String memento ;
if ( memento.isEmpty() )
do not compile.
It also was not working because of runtime exceptions in the
createMemoryTabsFromMemento(...) routine. The call to
fGotoAddressBar.addExpressionToHistory(...);
performGo(true, address, finalMemorySpace);
caused exceptions to occur. Perhaps this is because I am using
1.5 and you were using 1.6. It was complaining about the threading
not matching. So I added a runnable to make sure those operations
are in the UI dispatch thread.
Once this was done it seemed to work much better. I have created a
a new patch with these changes. Please check to insure my changes
are correct.
Randy
Randy, I tried your patch and your changes look ok to me! After some more testing, I found out that putting the tab creation code in a runnable didn't work because it wasn't catching the failures. In our debug model, sometimes the active context is one from which you can't read memory and creating a tab fails in this case. My patch keeps trying to restore the tabs until a valid context is passed to handleDebugContext(). The fix was to put the tab creation code in a callable instead. I'll update the patch. Created attachment 190704 [details]
Updated patch to create tabs in a callable instead of a runnable.
Created attachment 190778 [details] Updated patch to include fix for "Widget is diposed" exception in bug 338545 New Gerrit change created: https://git.eclipse.org/r/84694 Does it make sense to re-open tabs on addresses that may not represent the same things in the next debug session? (In reply to Marc Khouzam from comment #11) > Does it make sense to re-open tabs on addresses that may not represent the > same things in the next debug session? Yes, I think so. While sometimes it may move, I think the common use case would be relaunching with the same executable. In addition the use case of pointing memory at mem mapped registers makes this valuable. Finally, I think the pain of having to close (or change address on) a few addresses that are not relevant anymore is less than losing all settings. (In reply to Jonah Graham from comment #12) > (In reply to Marc Khouzam from comment #11) > > Does it make sense to re-open tabs on addresses that may not represent the > > same things in the next debug session? > > Yes, I think so. While sometimes it may move, I think the common use case > would be relaunching with the same executable. In addition the use case of > pointing memory at mem mapped registers makes this valuable. Finally, I > think the pain of having to close (or change address on) a few addresses > that are not relevant anymore is less than losing all settings. Sounds good. New Gerrit change created: https://git.eclipse.org/r/86958 (In reply to Eclipse Genie from comment #14) > New Gerrit change created: https://git.eclipse.org/r/86958 That version was abandoned. Correct one is from Comment 10: https://git.eclipse.org/r/84694 |