Community
Participate
Working Groups
Inserting break points from the Editor while Running two debug sessions in not stop mode may cause the insert to be immediately followed by a delete. See the traces from each session below: Traces for session related to the break point: 006,370 559-break-insert -f /home/lmcalvs/git/CDT-Samples/Producer/src/Producer.cpp:155 006,371 559^done,bkpt={number="138",type="breakpoint",disp="keep",enabled="y",addr="0x0000000000400e\ ad",func="main()",file="../src/Producer.cpp",fullname="/home/lmcalvs/git/CDT-Samples/Producer/src/Pr\ oducer.cpp",line="155",thread-groups=["i1"],times="0",original-location="/home/lmcalvs/git/CDT-Sampl\ es/Producer/src/Producer.cpp:155"} 006,371 (gdb) 006,480 560-break-delete 138 006,480 560^done 006,481 (gdb) Traces for the session unrelated to the break point: 006,370 113-break-insert -f /home/lmcalvs/git/CDT-Samples/Producer/src/Producer.cpp:155 006,371 &"No source file named /home/lmcalvs/git/CDT-Samples/Producer/src/Producer.cpp.\n" 006,372 113^done,bkpt={number="26",type="breakpoint",disp="keep",enabled="y",addr="<PENDING>",pendin\ g="/home/lmcalvs/git/CDT-Samples/Producer/src/Producer.cpp:155",times="0",original-location="/home/l\ mcalvs/git/CDT-Samples/Producer/src/Producer.cpp:155"} 006,373 (gdb)
An additional observation, The breakpoints are not installed if another session is already running before starting the second one. This can be seen in the breakpoints view right after starting the second session.
(In reply to Alvaro Sanchez-Leon from comment #1) > An additional observation, > > The breakpoints are not installed if another session is already running > before starting the second one. > This can be seen in the breakpoints view right after starting the second > session. This is unbelievable! I will post a fix soon. I will try to respin 8.5 for this. The reason I didn't notice this before is that when I run two sessions, they are usually using the same binary, so the install marker of the bp is already showing and I didn't realize it the bp were not being installed on the second session. Great find Alvaro.
Proposed fix: https://git.eclipse.org/r/33517
(In reply to Marc Khouzam from comment #3) > Proposed fix: > https://git.eclipse.org/r/33517 Committed to cdt_8_5 and re-spun RC4. I have to work on a fix for master, and look deeper to see if the fix for comment 1 fixes comment 0.
(In reply to Marc Khouzam from comment #4) > I have to work on a fix for master, and look deeper to see if the fix for > comment 1 fixes comment 0. Unfortunately issue on comment 0 is still present after the fix for comment 1
Here is the fix for master for the second session not getting breakpoints: https://git.eclipse.org/r/33573
(In reply to Alvaro Sanchez-Leon from comment #0) > Inserting break points from the Editor while Running two debug sessions in > not stop mode may cause the insert to be immediately followed by a delete. > See the traces from each session below: This seems to be another race condition where the two different executor try to create the filter class at the same time and end up creating two of them, instead of sharing the same one. I have to see why this wasn't happening before.
(In reply to Marc Khouzam from comment #8) > (In reply to Alvaro Sanchez-Leon from comment #0) > > Inserting break points from the Editor while Running two debug sessions in > > not stop mode may cause the insert to be immediately followed by a delete. > > See the traces from each session below: > > This seems to be another race condition where the two different executor try > to create the filter class at the same time and end up creating two of them, > instead of sharing the same one. > > I have to see why this wasn't happening before. I am able to reproduce this with Kepler! Looks like it has been here for a very long time. Maybe from the very start.
(In reply to Marc Khouzam from comment #9) > I am able to reproduce this with Kepler! > Looks like it has been here for a very long time. Maybe from the very start. Looking at the history, I believe this bug was introduced when fixing breakpoint filters in bug 355833. This was in Sept 2011, three years ago. The issue (breakpoint being deleted on target right after being created) is subject to a race condition which can only happen when running more than one debug session. It explains why this went unnoticed for so long.
(In reply to Marc Khouzam from comment #10) > (In reply to Marc Khouzam from comment #9) > > > I am able to reproduce this with Kepler! > > Looks like it has been here for a very long time. Maybe from the very start. > > Looking at the history, I believe this bug was introduced when fixing > breakpoint filters in bug 355833. This was in Sept 2011, three years ago. > > The issue (breakpoint being deleted on target right after being created) is > subject to a race condition which can only happen when running more than one > debug session. It explains why this went unnoticed for so long. Here is what happens. With two DSF debug sessions there are two Executors and two MIBreakpointsManager classes. When a new breakpoint is created in the platform, both MIBpManagers get called, and each one wants to add its processes to the bp filter. The bp filter class is unique for the breakpoint. So both MIBpManagers.getFilterExtension() get called for the same breakpoint and are expected to return the same class. However, since the bp was just created, that class does not exist yet and needs to be created by CBreakpoint.getExtensionsForModelId(). That method is not thread-safe and it happens that two different bp extension classes get created which screws up the filtering. I have proposed a fix which synchronized CBreakpoint.getExtensionsForModelId(): https://git.eclipse.org/r/33620 Theoretically, this synchronization issue could happen to any debugger integration using that extension mechanism.
(In reply to Marc Khouzam from comment #11) > I have proposed a fix which synchronized > CBreakpoint.getExtensionsForModelId(): > https://git.eclipse.org/r/33620 Committed to master
