Community
Participate
Working Groups
On 09/30/2010 10:45 AM, Chuong, Patrick wrote: > > > > I am having a problem when breakpoint changed event is fired multiple times quickly, the breakpoint group is collapsed. It looks like BreakpointVMProvider can’t handle multiple change notifications without some kind of delay in between. > > > > To reproduce, start a gdb-dsf debug session and set a line breakpoint. Group the breakpoint by type and than click on the breakpoint checkbox or modify the breakpoint properties. I am not sure how easily it can be reproduced with gdb-dsf environment, but it can be done if you modify BreakpointVMProvider.IBreakpointListener.breakpointChanged to call handleEventInExecThread two times in a loop. > > > > Is this a bug in the DSF BreakpointVMProvider or there is something that I shouldn’t be doing? It looks like there is a race condition between the cached data and the viewer. > > > > Regards, > Patrick
Created attachment 180259 [details] Fix This fix takes care of the problem as reproduced by the suggested method. BTW, I first tried to reproduce the problem by clicking fast on the breakpoint group (to enable/disable breakpoint), until I realized that double-clicking a tree item expanded/collapsed it too. The fix is to return an error from the cache when the data has been reset by another event. Before the change, the cache would return a child count '0' for the root node causing it to collapse. However, this fix is sort of a band-aid. The breakpoint VM implementation was something of an experiment (as was the platform one) and it's likely that we'll find more issues as we use it more. So it would be good to proactively invest time in tests and architecture changes.
I committed the fix. Patrick please mark bug as verified if it solves the problem for you.
I still see the tree collapsed problem. Using gdb you can simulate what I see in our dsf base debugger, fire two change events in the BreakpointVMProvider for each platform change event. By adding a loop in the BreakpointVMProvider.IBreakpoitnListener.breakpointsChange handler to call handleEventInExecThread twice. Also, I get a nullpointer in the second update in the patch, where getData() can be null, with or without the change in BreakpointVMProvider.
(In reply to comment #3) > I still see the tree collapsed problem. Using gdb you can simulate what I see > in our dsf base debugger, fire two change events in the BreakpointVMProvider > for each platform change event. By adding a loop in the > BreakpointVMProvider.IBreakpoitnListener.breakpointsChange handler to call > handleEventInExecThread twice. That's what I did also. Maybe you can post a code snippet of your loop. > > Also, I get a nullpointer in the second update in the patch, where getData() > can be null, with or without the change in BreakpointVMProvider. Don't see this either. Can you give the trace?
here is the change that I put in to simulate multipel change events public void breakpointsChanged(...) { for (int i = 0; i < 2; ++i) handleEventInExecThread(new BreakpointsChangedEvent (BreakpointsChangedEvent.Type.CHANGED, breakpoints)); } I am not sure what trace you are looking for. Can you let me know which trace option you want me to enable? here is the nullpointer exception: Caused by: java.lang.NullPointerException at org.eclipse.cdt.dsf.debug.ui.viewmodel.breakpoints.BreakpointOrganizerVMNode$3.handleCompleted(BreakpointOrganizerVMNode.java:84) at org.eclipse.cdt.dsf.concurrent.RequestMonitor$2.run(RequestMonitor.java:291) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134) ... 23 more here is the delta trace: RECEIVED DELTA: Model Delta Start Element: org.eclipse.cdt.dsf.debug.ui.viewmodel.breakpoints.BreakpointVMInput@b5723eb3 Flags: CONTENT | Index: 0 Child Count: -1 Model Delta End STATE APPEND BEGIN: null APPEND DELTA: Model Delta Start Element: org.eclipse.cdt.dsf.debug.ui.viewmodel.breakpoints.BreakpointVMInput@b5723eb3 Flags: CONTENT | EXPAND | Index: -1 Child Count: 1 Element: L/java/src/main.java Flags: CONTENT | EXPAND | SELECT | Index: 0 Child Count: 1 Element: Java Line Breakpoints Flags: CONTENT | EXPAND | Index: 0 Child Count: 1 Model Delta End APPEND OUTSTANDING RESTORE: Model Delta Start Element: org.eclipse.cdt.dsf.debug.ui.viewmodel.breakpoints.BreakpointVMInput@b5723eb3 Flags: CONTENT | EXPAND | Index: -1 Child Count: 1 Element: L/java/src/main.java Flags: CONTENT | EXPAND | SELECT | Index: 0 Child Count: 1 Element: Java Line Breakpoints Flags: CONTENT | EXPAND | Index: 0 Child Count: 1 Model Delta End SKIPPED: L/java/src/main.java SKIPPED: Java Line Breakpoints STATE APPEND COMPLETE Model Delta Start Element: org.eclipse.cdt.dsf.debug.ui.viewmodel.breakpoints.BreakpointVMInput@b5723eb3 Flags: CONTENT | EXPAND | Index: -1 Child Count: 1 Element: L/java/src/main.java Flags: CONTENT | EXPAND | SELECT | Index: 0 Child Count: 1 Element: Java Line Breakpoints Flags: CONTENT | EXPAND | Index: 0 Child Count: 1 Model Delta End I workaround the nullpointer issue by checking data is null or not, if null than set child count to zero.
Did you actually apply the patch or just make the corresponding changes? Because, I changed handleCompleted() to handleSuccess().
I didn't apply the patch, after changing the handler to succeed, it works very nice. Thank you for the quick fix. The fix is pretty minor, can it be port back to CTD 7.x? I don't see any where I can mark this bug verified, maybe I am not a committer?
You can just change the status from Resolved to Verfied :-)
I don't think I could. The status is a link, under the 'Additional Comments' edit control and at the top. I can click on it, but doesn't allow me to change the state of this Bug. Am I looking at the right place?
Yes, I guess it is a committer thing, which I think you ought to be by now...
