[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[cdt-dev] Spurious -list-thread-groups after disconnect from DSF-GDB session
|
I am observing occasional "-list-thread-groups" MI commands issued after
ending a DSF-GDB debug session using the "Disconnect" action. For example:
> 089,870 (gdb)
> 095,634 34-target-detach 1486
> 095,637 =thread-group-exited,id="1486"
> 095,637 34^done
> 095,637 (gdb)
> 095,645 35-gdb-exit
> 095,645 36-data-evaluate-expression $_exitcode
> 095,646 37-list-thread-groups
> 095,648 35^exit
I believe these are triggered by ThreadVMNode updates following a debug
context change event. Sometimes the update is delayed sufficiently to
observe this behaviour.
Most of the time this behaviour is harmless, but sometimes the
"-list-thread-groups" command occurs before the final "-gdb-exit"
command is issued:
> 336,496 (gdb)
> 338,617 83-target-detach i1
> 338,633 =thread-exited,id="1",group-id="i1"
> 338,633 =thread-group-exited,id="i1"
> 338,633 83^done
> 338,633 (gdb)
> 338,634 84-list-thread-groups
> 338,634 =thread-group-started,id="i1",pid="42000"
> 338,634 =thread-created,id="1",group-id="i1"
> 338,634 ~"[New Thread 42000.1]\n"
> 338,634 *running,thread-id="1"
> 338,634 84^done,groups=[{id="i1",type="process",pid="42000",executable="......."}]
> 338,634 (gdb)
> 338,712 85-gdb-exit
> 338,712 86-list-thread-groups --available
> 338,712 87-var-create --thread-group i1 - * &main
> 338,713 85^exit
> 338,713 =thread-exited,id="1",group-id="i1"
> 338,713 =thread-group-exited,id="i1"
In the above case, the "-list-thread-groups" MI command was issued
between the "-target-detach" and "-gdb-exit" commands. This causes GDB
to raise "thread-group-started" and "thread-started" events. The
resulting ContainerStartedDMEvent/ContainerExitedDMEvent pair causes
memory monitor persistence to fail. In fact, the memory monitors are
persisted to XML correctly on the first ContainerExitedDMEvent and then
overwritten by a zero-length set on the second ContainerExitedDMEvent.
I am wondering how to best suppress the ThreadVMNode update (which
triggers "-list-thread-groups") when the thread has already exited. Any
ideas?
John Dallaway
