Re: [cdt-dev] Spurious -list-thread-groups after disconnect from DSF-GDB

[John Dallaway <john@xxxxxxxxxxxxxxx>]

Has anyone else seen this issue?

I am currently working around this by using an "alreadySaved" flag in
MemoryBlockRetrievalManager which prevents calling
DsfMemoryBlockRetrieval.saveMemoryBlocks() more than once per session.
But there must be a more elegant way to avoid "-list-thread-groups"
after "-target-detach". Ideas are welcome...

John Dallaway


-------- Original Message --------
Subject: [cdt-dev] Spurious -list-thread-groups after disconnect from
DSF-GDB session
Date: Thu, 20 Mar 2014 13:26:16 +0000
From: John Dallaway <john@xxxxxxxxxxxxxxx>
Reply-To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
To: cdt-dev@xxxxxxxxxxx

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