Community
Participate
Working Groups
Created attachment 190654 [details] Proposed patch Breakpoints created outside Eclipse by another client are currently not displayed in Eclipse. This patch creates transient non-persisted breakpoint markers on the fly for such breakpoints (if possible).
The code in TCFBreakpointStatusListener patch is prone to racing conditions. It causes the list of transient breakpoints to get out of sync if events are coming in too fast. I can reproduce the problem by pressing and holding Ctrl+Shift+B in second instance of Eclipse. I am going to work on a fix for the racing before committing the code. Thanks!
I'v made changes to solve synchronization problems and committed the code. There are still some issues that we need to consider before closing the bug: 1. Enabling/disabling/modifying breakpoints is not properly propagated to second client GUI. 2. User can modify foreign breakpoints, but it has not effect on a target. I would prefer foreign breakpoints to be read-only. 3. Watchpoints are shown as line breakpoints in second client. 4. Deleting of foreign breakpoints causes a lot of exceptions in CDT code: org.eclipse.debug.core.DebugException: Breakpoint does not have an associated marker. It looks like CDT does not do proper locking of workspace data when updating Breakpoints view. It might be related to #5: 5. ResourcesPlugin.getWorkspace().getRuleFactory().markerRule(resource) always returns null. This causes fatal racing. I have changed the code to use modifyRule() to avoid the racing, but I'm not sure what is the right way to schedule breakpoint updates in Eclipse.
Created attachment 190869 [details] Follow up fix (In reply to comment #2) > I'v made changes to solve synchronization problems and committed the code. Thanks! > There are still some issues that we need to consider before closing the bug: > > 1. Enabling/disabling/modifying breakpoints is not properly propagated to > second client GUI. This is fixed with this patch. > 2. User can modify foreign breakpoints, but it has not effect on a target. I > would prefer foreign breakpoints to be read-only. Unfortunately I don't know of a way to make breakpoints read-only. This patch allows at least keeps the breakpoint states in sync. > 3. Watchpoints are shown as line breakpoints in second client. I've fixed that. > 4. Deleting of foreign breakpoints causes a lot of exceptions in CDT code: > org.eclipse.debug.core.DebugException: Breakpoint does not have an associated > marker. > It looks like CDT does not do proper locking of workspace data when updating > Breakpoints view. It might be related to #5: I see this only when breakpoints are created/deleted rapidly. Under "normal" conditions this did not occur. A fix for this would probably need to go into the platform to protect from marker changes/removal while updating the breakpoint labels. > 5. ResourcesPlugin.getWorkspace().getRuleFactory().markerRule(resource) always > returns null. This causes fatal racing. I have changed the code to use > modifyRule() to avoid the racing, but I'm not sure what is the right way to > schedule breakpoint updates in Eclipse. I think the reason for the null rule is that it should always be allowed to create markers so that you can e.g. set a breakpoint while the workspace is built or problem markers for compiler errors can be created. It does open the door for race conditions, though.
OK. It looks great. Committed. Thanks!
Comment on attachment 190869 [details] Follow up fix Anton was elected TCF committer on 24-Mar-2011: http://dev.eclipse.org/mhonarc/lists/tcf-dev/msg00028.html Thus any contributions before that time must be marked iplog+
