Community
Participate
Working Groups
I just noticed that when the program jumps within a method, the variables view is not updated properly. It keeps partial data from what it used to show. Once another step is taken, everything is updated. Try this: - set a breakpoint inside a method other than main - run the program with Stop at main - have variables view open - resume until breakpoint - notice that variables view show a subset of the variables of main instead of the variables of the new method. - step and everything will get fixed. This is not the case of the expressions view. Because of M5, I wrote the bug before looking into it, in case someone else can find something faster than I can.
Note that this bug dates back to at least February 8th (before the renaming), since I was able to reproduce it on an old workspace of mine.
I'm trying to investigate this bug, but so far I haven't been able to reproduce it. I'm using the SanityTest program and I'm setting a breakpoint inside the test* functions. Are you able to reproduce this bug consistently, or is it intermittent?
The method you have the breakpoint must have less variables (including arguments) than the one you were previously in. I'm currently in AbstractCachingVMProvider::updateNode trying to figure out why the VMChildrenUpdate has an offset of 2 (I had two variables in my method.)
Its some kind of refresh problem in the variables view. When the program stops, my view is showing the right number of variables, but with the old content. If I hide the variables view and show it again, everything is ok.
Now, I'm thinking it has to do with update policy. When I see the problem and I click the refresh button, the view displays properly. However, how do I check my update policy in the variables view? When I open up the menu and click "update policy" nothing happens
(In reply to comment #5) > Now, I'm thinking it has to do with update policy. > When I see the problem and I click the refresh button, the view displays > properly. I definitely wouldn't rule out update policy as the issue, especially given that bug 208476 is a timing-related cache bug that is still outstanding. However, if the update cache was the problem hiding the view then re-displaying it shouldn't correct the problem. So I think a timing issue in the viewer could also be a problem. Since I still can't reproduce the problem I'd like you to turn on some tracing in the viewer reproduce the problem and attach the trace to this bug. To turn on the tracing, edit the org.eclipse.debug.ui/.options file to the following: org.eclipse.debug.ui/debug = true org.eclipse.debug.ui/debug/viewers/model = false org.eclipse.debug.ui/debug/viewers/viewer = false org.eclipse.debug.ui/debug/viewers/deltas = true org.eclipse.debug.ui/debug/viewers/contentProvider = true org.eclipse.debug.ui/debug/viewers/updateSequence = false org.eclipse.debug.ui/debug/contextlaunching = false org.eclipse.debug.ui/debug/launchhistory = false or set the equivalent in the Tracing tab of the debug launch. > However, how do I check my update policy in the variables view? > When I open up the menu and click "update policy" nothing happens The update policy menu does indeed seem broken. I filed a separate bug 219124 for it.
(In reply to comment #6) I'll get you the traces, but in the mean time, I was able to reproduce with the Sanity test, by setting a breakpoint in test_stack. Unless my update policy is different than yours...
(In reply to comment #7) > (In reply to comment #6) > I'll get you the traces, but in the mean time, I was able to reproduce with the > Sanity test, by setting a breakpoint in test_stack. > Unless my update policy is different than yours... The update policy is "automatic" by default, and for now it's reset with every launch, so that's not likely a difference. If this is a timing issue, I wonder if anyone else has observed it yet.
I reproduced it. I finally installed the release bits and I was able to reproduce it (by not running with debugger attached). No need to add the trace, I'll do it locally.
Created attachment 89868 [details] Traces requested (just in case) Since I just finished collecting the traces, I attached them anyway. More info cannot hurt. Note that I was able to reproduce while debugging the DSF code... (but these traces were in a normal run.)
Oh, and I put comments starting with a # through out the file to show which steps I was taking (e.g., resuming, hiding variable view, etc)
Most likely this bug is a new version of bug 202109 that ted discovered in the fall. The refactoring of the vm classes and the caching probably caused it to resurface. I'll investigate a little more, but we may need to wait till M6 to fix it.
Created attachment 89872 [details] Patch with fix. It turned out to be a logic bug in the update modes cache, not related to 202109.
Marking as fixed in M6, if decide to re-spin the build this bug will be included in M5. Ted since you implemented the original caching logic, could you please review the fix.
Created attachment 89875 [details] Broken debug view 1 I tried the fix and it does fix my variables view problem. However, the debug view is now a bit broken. First attachment shows that the last process is always missing when launching the program. The second attachment will show that after stopping at the breakpoint, the debug view does not refresh properly. Also, it seems the expression view is completely broken. It only shows partial results, and seems to hang.
Created attachment 89876 [details] Broken debug view 2 Debug view broken image
Yikes! I reproduced the problem and also noticed an IndexOutOfBoundException coming from DefaultVMContentProvider. I think fixing this bug made bug 218573 worse.
Created attachment 89882 [details] Patch to fix the IndexOutOfBoundsException I committed a fix to guard against the IndexOutOfBoundsException because it leaves the Debug view in an inconsistent state. But the rest of the processes issue shoudl be tracked in bug 218573.
(In reply to comment #18) The expression view is still busted. Try launching with the expression view showing which seems to impact the debug view negatively. But opening the expression view after is also broken.
I think I just better re-open this bug. The expression view triggers another IndexOutOfBoundsException, and when I tried fixing that exception I got plenty of other anomalies. I'll have to investigate this bug after M5. Caused by: java.lang.IndexOutOfBoundsException: Index: 1, Size: 1 at java.util.LinkedList.entry(LinkedList.java:368) at java.util.LinkedList.remove(LinkedList.java:360) at org.eclipse.dd.dsf.ui.viewmodel.update.AbstractCachingVMProvider.updateNode(AbstractCachingVMProvider.java:419) at org.eclipse.dd.dsf.ui.viewmodel.DefaultVMContentProviderStrategy.update(DefaultVMContentProviderStrategy.java:211) at org.eclipse.dd.dsf.ui.viewmodel.AbstractVMProvider.update(AbstractVMProvider.java:314) at org.eclipse.dd.dsf.ui.viewmodel.AbstractVMAdapter$2.run(AbstractVMAdapter.java:139)
Created attachment 90086 [details] Patch with final fix (hopefully).
I think I finally figured out the bug, it was another logic error in the cache code. Ted, when you have time to look at this code please review this logic.
(In reply to comment #22) > I think I finally figured out the bug, it was another logic error in the cache > code. Ted, when you have time to look at this code please review this logic. > From my end, all the problems I was seeing are gone. Thanks for the fix!
Closing out 1.0 bugs.
