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

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

alain,

i think that the problem being that 'kill' isn't the last command to be
sent. As part of a terminate, a suspend event is processed followed by a
kill. However, as part of a suspend event, there is a postCommand0 for
thread/stack information as well. What's happening, is that the kill
command is being interleaved with the processing of the suspend event so
you end up with the queue having (for example)
 > info variables
 > kill
 > info threads
 > info registers
 > ...
 > gdb_exit

So then the inferior completes its termination and closes its streams,
meanwhile new commands are still coming in from the suspendEvent.
However, the MISession.postCommand0(...) function isn't aware of that
the inferior has actually terminated (and closed all its streams), so it
then throws the MIException (Target_not_responding), which gets caught
and ignored in the EventManager. 

I'm trying to put a patch together which will check within
MISession.postCommand0(...) if the inferior is terminated before adding
the cmd to the txQueue, and throw an exception if it is. This exception
can then be caught in the EventManager.processSuspendedEvent(), and have
the command's token added to the ignoreEventToken list so it's ignored
in the update(...) function.  Is this a reasonable solution, and if so,
are there other cases/functions which need to be modified to handle this
change?  Otherwise, can you point me in the direction for creating a
solution? 

I'll be happy to submit a patch to you with my proposed fix when it's
done.

thanks in advance,
li-wei

> 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

_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev