Community
Participate
Working Groups
Build Identifier: I20110127-2034 If you open a bunch of memory tabs in the memory browser view, terminate the launch, and then re-launch the configuration, I was expecting to see the same memory tabs re-opened, but the memory view is empty after a re-launch. This would save the user the trouble of re-opening the memory tabs each time he re-launches the debug configuration. Reproducible: Always Steps to Reproduce: 1. launch a debug configuration 2. open a memory browser view 3. type an address like 0 in the address bar and press the Go button. A tab showing memory from address 0 onward is now visible. 4. type a different address like 1000 in the address bar and press the New Tab button. A tab showing memory from address 1000 onward is now visible. 5. terminate the launch 6. re-launch the same debug launch configuration. The memory browser view is empty (no open tabs). I was expecting the previously open tabs to re-appear.
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
