Bugzilla – Full Text Bug Listing
| Summary: | DSF-GDB breakpoint deleted when modifying thread filter | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | John Dallaway <john> | ||||||||
| Component: | cdt-debug-dsf-gdb | Assignee: | Marc Khouzam <marc.khouzam> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | Marc Khouzam <marc.khouzam> | ||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | cdtdoug, nobody, pawel.1.piech, shaijupnairp | ||||||||
| Version: | 8.0 | Flags: | marc.khouzam:
review?
(nobody) |
||||||||
| Target Milestone: | 8.0.1 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
I must have broken something when I played with breakpoints for multi-process. I don't have time right now to look at it, but this should be fixed for the maintenance release. Marc, FYI, the DMContexts.isAncestorOf() test in MIBreakpointsManager#extractThreads() returns false so the Set of threads returned by extractThreads() is empty. When debugging I found that if user applies/removes the break-point filter the on any break-point ' IContainerDMContext ' objects of that debug session is stored inside the filter extension object (IDsfBreakpointExtension object ) corresponding to that break-point. When the debug session (or launch ) is terminated these objects are not cleared from the filter extension object , it holds these IContainerDMContext object which in turns holds reference to session, gdb process etc all of which are actually dead. This is cleared only when we exit the workbench. It may not be causing any trouble at the moment but seems incorrect . (In reply to comment #3) > When debugging I found that if user applies/removes the break-point filter the > on any break-point ' IContainerDMContext ' objects of that debug session is > stored inside the filter extension object (IDsfBreakpointExtension object ) > corresponding to that break-point. When the debug session (or launch ) is > terminated these objects are not cleared from the filter extension object , it > holds these IContainerDMContext object which in turns holds reference to > session, gdb process etc all of which are actually dead. > > This is cleared only when we exit the workbench. It may not be causing any > trouble at the moment but seems incorrect . Thanks Shaiju, I've opened Bug 355828 to track this. Created attachment 202157 [details]
Fix
The problem was caused by the changes for multi-process. Previously, the IBreakpointsTargetDMContext was the CommandControlDMC which was an ancestor of the container. With multi-process, the IBreakpointsTargetDMContext has become the container itself, so the call to DMContexts.isAncestorOf() fails. I added a check for equals().
This patch also makes some strings translatable because they had been marked as NLS by mistake.
Finally, when running multiple processes, the name of the process was not obtained properly.
I will commit to master and 8_0.
John, can you confirm this fixes things for you? Mikhail, can you review? *** cdt git genie on behalf of Marc Khouzam ***
Bug 349736: DSF-GDB breakpoint deleted when modifying thread filter
[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=e5c813169a1553fb637400384a0cc4b2d27dc429
*** cdt git genie on behalf of Marc Khouzam ***
Bug 349736: DSF-GDB breakpoint deleted when modifying thread filter
[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=0b1aec3226f84f728f9b37576d917f75a4a2d448
Marc, thanks for looking at this. Unfortunately, your patch has not resolved the issue for me. The modified test ((ctxt.equals(context) || DMContexts.isAncestorOf(ctxt, context)) in MIBreakpointsManager#extractThreads() is still failing. When I place a breakpoint on this line, I can see that "ctxt" and "context" have different IDs: ctxt: gdb[1].proc[].threadGroup[] context: gdb[1].proc[].threadGroup[null] I hope this info helps in tracking down this issue. Let me know if I can assist with any further info. (In reply to comment #9) > Marc, thanks for looking at this. Unfortunately, your patch has not resolved > the issue for me. The modified test ((ctxt.equals(context) || > DMContexts.isAncestorOf(ctxt, context)) in > MIBreakpointsManager#extractThreads() is still failing. When I place a > breakpoint on this line, I can see that "ctxt" and "context" have different > IDs: > > ctxt: gdb[1].proc[].threadGroup[] > context: gdb[1].proc[].threadGroup[null] > > I hope this info helps in tracking down this issue. Let me know if I can assist > with any further info. I don't believe there should be a null threadGroup. This looks a bug to me. Which version of GDB are you using? What is the scenario that leads to a null groupId? (In reply to comment #10) > I don't believe there should be a null threadGroup. This looks a bug to me. > Which version of GDB are you using? What is the scenario that leads to a null > groupId? I am using arm-eabi-gdb 6.8.50.x. I simply create a breakpoint while the application is suspecded and then immediately modify the filter properties. My application has four threads and a single process. Note that I had tried using arm-eabi-gdb 7.0 some time ago (before your patch) without success. I have just retested using arm-eabi-gdb 7.0 (with your patch) and the reported problem is no-longer seen: ctxt: gdb[1].proc[42000].threadGroup[42000] context: gdb[1].proc[42000].threadGroup[42000] So I believe the patch has fixed the reported issue when using GDB 7.0 but not when using earlier versions of GDB. (In reply to comment #11) > I have just retested using arm-eabi-gdb 7.0 (with your patch) and the reported > problem is no-longer seen: > > ctxt: gdb[1].proc[42000].threadGroup[42000] > context: gdb[1].proc[42000].threadGroup[42000] > > So I believe the patch has fixed the reported issue when using GDB 7.0 but not > when using earlier versions of GDB. Right, so the equals() test works for the above contexts, but not for GDB 6.8 which seems to yield: ctxt: gdb[1].proc[].threadGroup[] context: gdb[1].proc[].threadGroup[null]. The thing is, in my case, with GDB 6.8, I don't see 'null' as the threadGroup, but I see "", which makes things work. When trying to reproduce it, I ran into another problem. When I use GDB 7.0 or 7.1, I get: ctxt: gdb[1].proc[].threadGroup[] context: gdb[1].proc[42000].threadGroup[42000] This is a problem I ran into before in Bug 336890. But I missed the scenario of thread filters. I'm surprised your ctxt variable has the 42000 threadGroup and proc set... All this works properly with GDB >= 7.2, but apparently no so much with olders GDBs. Marc (In reply to comment #12) > When trying to reproduce it, I ran into another problem. When I use GDB 7.0 or > 7.1, I get: > > ctxt: gdb[1].proc[].threadGroup[] > context: gdb[1].proc[42000].threadGroup[42000] > > This is a problem I ran into before in Bug 336890. But I missed the scenario > of thread filters. I'm surprised your ctxt variable has the 42000 threadGroup > and proc set... I can reproduce the above using native GDB 7.0.1 and pthreads, but with ctxt and context IDs swapped relative to your report: ctxt: gdb[2].proc[18631].threadGroup[18631] context: gdb[2].proc[].threadGroup[] It is not clear to me why the behaviour of my arm-eabi-gdb 7.0 tool would be different in this respect unless there is some pthreads-specific knowledge at the GDB-DSF level. I get "Thread[1]null" in the filter dialog because the "target-id" attribute is "process 31286". I get the same target id for GDB 7.2 and 7.3. Opening and closing the filter dialog seems to mark the breakpoint as deleted. It is still active in the current session but will not be set if the session is terminated and restarted. In the dialog it is shown as disabled for the entire target. (In reply to comment #14) > I get "Thread[1]null" in the filter dialog because the "target-id" attribute is > "process 31286". I get the same target id for GDB 7.2 and 7.3. This is a simple program without pthreads, with pthreads the labels are fine. (In reply to comment #14) > Opening and closing the filter dialog seems to mark the breakpoint as deleted. > It is still active in the current session but will not be set if the session is > terminated and restarted. In the dialog it is shown as disabled for the entire > target. This is happening for a program with one thread only. Seems to work fine for multiple threads. Marc, I think the reported issue may be related to the threading implementation. I have built a native gdb from my 6.8.50.x sources and thread filtering on a native pthreads application behaves correctly:
ctxt: gdb[1].proc[].threadGroup[]
context: gdb[1].proc[].threadGroup[]
Compare this with the IDs in comment #9 which are for a non-pthreads implementation of threading. Is it possible that code which calculates or looks up the threadGroup ID is failing in the case of GDB < 7.0 with non-pthreads threading?
(In reply to comment #17) > Marc, I think the reported issue may be related to the threading implementation. I am no-longer convinced that the threading implementation is relevant. My arm-eabi-gdb debug sessions are using the GDB Hardware Debugging launch type. It appears that the "null" threadGroup indicated in comment #9 is related to the following call in org.eclipse.cdt.debug.gdbjtag.core.GDBJtagDSFFinalLaunchSequence: fProcService.createContainerContextFromGroupId(fCommandControl.getContext(), null) If I replace the 2nd parameter (null) with an empty string ("") then the reported problem goes away. Does this make sense to you? (In reply to comment #14) > I get "Thread[1]null" in the filter dialog because the "target-id" attribute is > "process 31286". I get the same target id for GDB 7.2 and 7.3. > Opening and closing the filter dialog seems to mark the breakpoint as deleted. > It is still active in the current session but will not be set if the session is > terminated and restarted. In the dialog it is shown as disabled for the entire > target. Bug 355833. But there seems to be more than one issue about thread filters... (In reply to comment #18) > (In reply to comment #17) > > > Marc, I think the reported issue may be related to the threading implementation. > > I am no-longer convinced that the threading implementation is relevant. My > arm-eabi-gdb debug sessions are using the GDB Hardware Debugging launch type. > It appears that the "null" threadGroup indicated in comment #9 is related to > the following call in > org.eclipse.cdt.debug.gdbjtag.core.GDBJtagDSFFinalLaunchSequence: > > fProcService.createContainerContextFromGroupId(fCommandControl.getContext(), > null) > > If I replace the 2nd parameter (null) with an empty string ("") then the > reported problem goes away. > > Does this make sense to you? Good find! That is a bug. If you look for the other call to createContainerContextFromGroupId() in that class, it uses MIProcesses.UNIQUE_GROUP_ID. We should do that for both calls. (In reply to comment #20) > Good find! That is a bug. If you look for the other call to > createContainerContextFromGroupId() in that class, it uses > MIProcesses.UNIQUE_GROUP_ID. We should do that for both calls. John, do you want to submit a patch for this so I can give you credit for the fix? Created attachment 202589 [details]
Fix threadGroup ID in GDBJtagDSFFinalLaunchSequence
Created attachment 202600 [details]
Committed patch for Fix threadGroup ID in GDBJtagDSFFinalLaunchSequence
John's patch with copyright notice and update of plugin version.
I will commit to master and 8_0
*** cdt git genie on behalf of John Dallaway ***
Bug 349736: DSF-GDB breakpoint deleted when modifying thread filter
[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=98c81cf0fb7757780ea10161faa5b384792eea3e
(In reply to comment #13) > I can reproduce the above using native GDB 7.0.1 and pthreads, but with ctxt > and context IDs swapped relative to your report: > > ctxt: gdb[2].proc[18631].threadGroup[18631] > context: gdb[2].proc[].threadGroup[] You are right, I had them reversed. (In reply to comment #15) > (In reply to comment #14) > > I get "Thread[1]null" in the filter dialog because the "target-id" attribute is > > "process 31286". I get the same target id for GDB 7.2 and 7.3. > > This is a simple program without pthreads, with pthreads the labels are fine. Thanks Mikhail. Yet another bug. I opened Bug 356463 about it. (In reply to comment #23) > Committed patch for Fix threadGroup ID in GDBJtagDSFFinalLaunchSequence Thank you, Marc. *** cdt git genie on behalf of John Dallaway ***
Bug 349736: DSF-GDB breakpoint deleted when modifying thread filter
[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=9a2af849799f34b984a6f19c84e02571202a8fb7
(In reply to comment #13) > Marc > > (In reply to comment #12) > > > When trying to reproduce it, I ran into another problem. When I use GDB 7.0 or > > 7.1, I get: > > > > ctxt: gdb[1].proc[].threadGroup[] > > context: gdb[1].proc[42000].threadGroup[42000] > > > > This is a problem I ran into before in Bug 336890. But I missed the scenario > > of thread filters. I'm surprised your ctxt variable has the 42000 threadGroup > > and proc set... > > I can reproduce the above using native GDB 7.0.1 and pthreads, but with ctxt > and context IDs swapped relative to your report: > > ctxt: gdb[2].proc[18631].threadGroup[18631] > context: gdb[2].proc[].threadGroup[] > > It is not clear to me why the behaviour of my arm-eabi-gdb 7.0 tool would be > different in this respect unless there is some pthreads-specific knowledge at > the GDB-DSF level. I opened Bug 356488 to track the problem with GDB 7.0 and 7.1. So, this bug brought forth a bunch of problems with thread filters. We now have Bug 355828, Bug 355833 and Bug 356488, as well as the already-fixed Bug 356463. The problem actually reported by the current should be fixed, so I'm resolving this bug. (In reply to comment #27) > (In reply to comment #23) > > > Committed patch for Fix threadGroup ID in GDBJtagDSFFinalLaunchSequence > > Thank you, Marc. Thank you for finding the actual problem :-) |
Build Identifier: Eclipse I20110526-1708 (3.7RC3) + CDT HEAD When modifying the thread filtering properties of a DSF-GDB breakpoint, the gdb trace indicates that the original breakpoint is deleted but the replacement breakpoint(s) are not created and the following Java console message is observed: !ENTRY org.eclipse.cdt.dsf 4 10002 2011-06-17 18:24:25.632 !MESSAGE Invalid breakpoint !SUBENTRY 1 org.eclipse.cdt.dsf.gdb 4 10002 2011-06-17 18:24:25.633 !MESSAGE Invalid breakpoint The breakpoint is still listed in the Breakpoints view but it no-longer exists at the GDB level. Issue observed when using GDB (DSF) Hardware Debugging Launcher with a multi-threaded single process application and GDB 6.8.50.x. Breakpoint thread filtering works correctly using the Standard GDB Hardware Debugging Launcher (CDI) to debug the same application. DSF trace when disabling a breakpoint for one of four threads: 401,923 58-break-delete 1 401,925 58^done 401,925 (gdb) CDI trace when disabling a breakpoint for one of four threads: 105-break-delete 9 105^done 106-break-insert -p 3 twothreads.c:61 (gdb) 106^done,bkpt={number="10",type="breakpoint",disp="keep",enabled="y",addr="0x0000c6dc",func="simple_program",file="../twothreads.c",fullname="/home/jld/workspace/twothreads/twothreads.c",line="61",thread="3",thread="3",times="0",original-location="twothreads.c:61"} 107-break-insert -p 1 twothreads.c:61 (gdb) 107^done,bkpt={number="11",type="breakpoint",disp="keep",enabled="y",addr="0x0000c6dc",func="simple_program",file="../twothreads.c",fullname="/home/jld/workspace/twothreads/twothreads.c",line="61",thread="1",thread="1",times="0",original-location="twothreads.c:61"} 108-break-insert -p 2 twothreads.c:61 (gdb) 108^done,bkpt={number="12",type="breakpoint",disp="keep",enabled="y",addr="0x0000c6dc",func="simple_program",file="../twothreads.c",fullname="/home/jld/workspace/twothreads/twothreads.c",line="61",thread="2",thread="2",times="0",original-location="twothreads.c:61"} (gdb) Reproducible: Always Steps to Reproduce: 1. Create a breakpoint within a DSF debug session (single process) 2. Modify the thread filter using the Breakpoint Properties dialog 3. Observe gdb trace