RE: [cdt-debug-dev] Re: [cdt-patch] MISession terminate patch

["Li-Wei Lee" <LWLEE@xxxxxxxxxx>]

PR #90089 has been submitted (and assigned to you) for the
TERMINATE/DISCONNECT events not reaching gdb before the EventThread is
able to process it.

> I'm also occasionally seeing cases (also when running on a remote 
> target), where it's failing to terminate a running target. What tends 
> to happen, is that when the target is running, selecting 
> Thread[Running] and terminating that results in gdbserver terminating 
> (reflected in the debug display window), but nothing else happens. The

> thread continues running as if nothing happened.  After that, if i 
> select the launch, and try to terminate, gdb will either eventually 
> die after a long delay (10 secs or so - timeout value?), or the debug 
> window thinks that it's dead and the launch terminates but the actual 
> gdb process remains active (and never dies). GDB console shows that a 
> kill has been sent, but the last 2 lines in the console are 
> "mi_cmd_stack_info_depth: No stack". When debugging the 
> runtime-workbench, it showed that MISession.terminate() is never 
> called so the "-gdb-exit" command never gets posted. I don't know if 
> this is a related issue or not.  Any thoughts?
> 
> One possibility:
> When the Target(Inferior) is running, gdb is non-responsive to 
> any commands.  The only way to get gdb's attention is to suspend the
target, meaning dropping a SIGINT on gdb. This may or may not work or
may 
> work with some delay.
Since a kill was sent out successfully, wouldn't that mean that the
SIGINT worked? When the launch does successfully terminate, gdb console
displays the following: 

<snip>
    kill
    info threads
    No registers.
    info threads
    No registers.
    Signal        Stop	Print	Pass to program	Description
    SIGTRAP       Yes	Yes	No		Trace/breakpoint trap
    info signal SIGTRAP
    info threads
    No registers.
    No breakpoint number 1.
</snip>

When there's a problem, all you see is :
<snip>
    kill
    mi_cmd_stack_info_depth: No stack
    mi_cmd_stack_info_depth: No stack
</snip>
Is it possible that gdbserver is exiting before that final commands can
be posted (info threads etc), so gdb ends up posting these commands, and
waiting indefinitely for a response from a terminated target?

> 
> gdb as a new option --async, for remote, for this option gdb is doing
a select(2)/poll(3) and still be responsive to command inputs.  So we
will be able 
> to use commands like:
> 	--exec-interrupt
> 
> but ... it does not work.
> 
> If you have more inputs on this, I would like to hear form it and work
on possible solutions.
> 
When debugging, i've noticed that the Rx/Tx/EventThreads are active when
the terminate fails, and a terminate event is never sent out - call to
handleDebugEvent is not triggered.

I've submitted PR #90090 to track this issue.

thanks,
li-wei