Bugzilla – Full Text Bug Listing
| Summary: | [breakpoints] Breakpoint "Enable" does not work after restarting the application | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Alvaro Sanchez-Leon <alvaro.sanchez-leon> |
| Component: | cdt-debug-dsf-gdb | Assignee: | Alvaro Sanchez-Leon <alvaro.sanchez-leon> |
| Status: | RESOLVED FIXED | QA Contact: | Marc Khouzam <marc.khouzam> |
| Severity: | normal | ||
| Priority: | P3 | CC: | cdtdoug, konradsa, pawel.1.piech |
| Version: | Next | ||
| Target Milestone: | 8.6.0 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | 442394 | ||
| Bug Blocks: | 457843 | ||
|
Description
Alvaro Sanchez-Leon
I have submitted a proposed fix for review at: https://git.eclipse.org/r/#/c/39154/ Sascha, could you give it a try in your environment ? (In reply to Alvaro Sanchez-Leon from comment #1) > I have submitted a proposed fix for review at: > > https://git.eclipse.org/r/#/c/39154/ Alvaro, can you explain the reason for the bug and the way to fix it? Thanks Alvaro and I have been investigating this more deeply and here is an explanation of what is happening. Recently, to fix Bug 442394, we've made modifications about hot the targetFilter is being set for a breakpoint. Before the fix, when a process was started we would wait for the IStartedDMEvent in MIBreakpointsManager and add the process to the filter. When a process would end, we would wait for an IExitedDMEvent and remove the process from the filter. This was nice and symmetric. It also worked for a restart, since when restarting a process an IExitedDMEvent is sent which removes the process from the filter, and then a new IStartedDMEvent was also sent, which added the process back to the filter. With Bug 442394, we found out that the IStartedDMEvent could take too long to arrive and we could therefore not rely on that. Instead, we started using startTrackingBpForProcess() which is explicitly called when creating a new process, but not when restarting one. However we still react to an IExitedDMEvent and remove the process from the filter, and this does happen for a restart. So, when the process restarts, it gets removed from the filter and never gets added back, so breakpoints no longer work as soon as they are modified (it is only on a modification that the MIBreakpointsManager.isBreakpointEntirelyFiltered() is called and notices the process is not in the filter and deletes the breakpoints). So we have two options to fix this: 1- Somehow add the process back to the filter after a restart. This is the approach Alvaro tried in https://git.eclipse.org/r/#/c/39154/1 This would behave as we used to when we used IStartedDMEvent to set the filter. However, I'm not a big fan of calling startTrackingBpForProcess() at a restart since we don't actually want to start tracking breakpoints again, just set the filter. It does work though because the call to startTrackingBpForProcess() realizes that it is for the same inferior and does not try to set breakpoints again. 2- Somehow don't remove the process from the filter in the case of a restart. This would follow the approach we used _before_ we moved to using IStartedDMEvent and IExitedDMEvent to deal with the filter. We are not sure yet what is the best way forward and will play around with the two options. (In reply to Alvaro Sanchez-Leon from comment #1) > I have submitted a proposed fix for review at: > > https://git.eclipse.org/r/#/c/39154/ > > > Sascha, could you give it a try in your environment ? Hi, will try to get to it soon. Will let you know. Thanks for your quick fix. Hi, was able to test the fix successfully, seems to work. Please approve the checkin. Hope we will make it in time for SR2 RC1. :-) Thanks! I have been Testing and discussing option 1 with Mark Khouzam, We can now see some issues: - MIBreakpointsManager may receive the process exited event after the break point filters have been re-initiated for a process being restarted. causing this same original problem. - Bringing the initialization step a bit later will not help as it could cause other problems e.g. skipping break points. Moving to option 2. I have now submitted patch set 2 with the following logic. - Updated MIBreakpointsManager to move the code after the reception of a process exit (used to remove the break point filters for the exiting process) to a new API method. - Updated GDBProcesses_7_2 to call the new API above only upon reception of a process exited event and if this process is NOT restarting. With the above changes the break point filtering will remain untouched for an exiting process being restarted and be removed otherwise. So this solution addresses the specific problem of a process being restarted with no impacts (expected :-)) to other scenarios. (In reply to Sascha Konrad from comment #5) > Hi, was able to test the fix successfully, seems to work. Please approve the > checkin. Hope we will make it in time for SR2 RC1. :-) Thanks! Sascha, we had to move to a different solution as explained in Comment 6 Could you give a try to patch set 2 ? Ok, I gave the second patch whirl too, seems to fix the problem as well. The solution is now merged, Thanks Marc and Sascha !! I wrote a test to reproduce this problem: https://git.eclipse.org/r/39970 (In reply to Marc Khouzam from comment #10) > I wrote a test to reproduce this problem: > https://git.eclipse.org/r/39970 This test uses gdb breakpoint synchronization with the gdb console, which only works starting with GDB 7.4. I've disabled this test for GDB < 7.4. http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=2c1113c590643b39fa74e8f2a09b391797b704c0 This is the reason Hudson was seeing failures on our full Debug tests. *** cdt git genie on behalf of Marc Khouzam ***
Bug 456959 - Disable test for versions of GDB that don't support it
Signed-off-by: Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>
[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=2c1113c590643b39fa74e8f2a09b391797b704c0
|