Community
Participate
Working Groups
In bug 338136 comment 18, Marc-Andre says: "While testing with gdb 6.8, I noticed the instruction pointer often not being removed after the launch was terminated. It seems to be OK with 7.0.1, 7.1 and 7.2." I was able to reproduce the is when selecting the launch node and terminating in a normal debug session. Like M-A says, it is for GDB 6.8 (and maybe earlier). I also don't see this problem with CDT 7.0. I've been modifying the terminating code as part of bug 338319. I must have missed something. My guess is some missing event, like containerExited, or commandControlExited.
I'm seeing this with GDB 7.2 also
The reason is that DsfSourceDisplayAdapter is expecting an IExitedDMEvent but it does not always receive it. For GDB >= 7.0, we rely on GDB's MI events to report our own IExitedDMEvent, but it seems that when terminating GDB, we close the streams before we get those events in some cases. I'm looking into it.
I believe it is my fix to Bug 345164 that makes this happen for GDB >= 7.0. What seems to happen is that we close the streams in GDBBackend.destroy() before we have received all the data from GDB, so we can miss some events.
Created attachment 196721 [details] Close the streams from the user of the stream This fix is for GDB >= 7.0. The problem was that we would close the streams too early in GDBBackend.destroy(), and miss some data given by GDB. This patch lets the actual user of the streams take care of closing it. This allows us to finish reading the stream and get all the data from GDB. With this change, I see that the IP is removed properly, because we get the proper IExitedDMEvent triggered from the GDB events: =thread-exited,id="1",group-id="i1" =thread-group-exited,id="i1" Committed to HEAD. Toni, can you review this fix?
*** cdt cvs genie on behalf of mkhouzam *** Bug 339379 : Instruction pointer is not always removed when terminating launch. Fix for GDB >= 7.0 [*] AbstractMIControl.java 1.18 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/command/AbstractMIControl.java?root=Tools_Project&r1=1.17&r2=1.18 [*] GDBBackend.java 1.28 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/GDBBackend.java?root=Tools_Project&r1=1.27&r2=1.28
Makes perfect sense.
Created attachment 196803 [details] Fix for GDB <= 6.8 This fix is for GDB <= 6.8. The problem was that the ContainerExitedDMEvent was not being sent at all when GDB itself was dying. Previously, when we received an ^exit from GDB, MIInferiorProcess would send that event. However, when I re-designed that part, I forgot to keep sending the event. My first attempt to fix this was to send the event in MIRunControlEventProcessor when we get the same ^exit. But I ran into a race condition where we sometimes call stopCommandProcessing() before we got the ^exit. This was because we would detect that GDB was dead through GDBBackend.MonitorJob which monitors the actual GDB process, before we got the ^exit. This patch sends the ContainerExitedDMEvent when we receive the ICommandControlShutdownDMEvent event. Committed to HEAD.
Fixed for all GDB versions
*** cdt cvs genie on behalf of mkhouzam *** Bug 339379: Instruction pointer is not always removed when terminating launch (GDB <= 6.8 solution) [*] GDBControl.java 1.31 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/command/GDBControl.java?root=Tools_Project&r1=1.30&r2=1.31
