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

["Alain Magloire" <alain@xxxxxxx>]

> 
> 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.=20
> 
> 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?=20
> 
> I'll be happy to submit a patch to you with my proposed fix when it's
> done.
> 

Ok, it seems you are on the right track.
To resume, your comments.  The target is running and we
try to terminate the session. A certain number of actions
are taken:

- Since the inferior is running we need to get gdb's attention
- SIGINT is dropped on gdb.
- gdb catches the SIGINT and interrupt the inferior
- The RxThread sees the infererior suspended:
   *stopped...
  and fire an (SUSPENDED) event back to the debug platform
- The debug platform starts is routine: asking threads info, stackframes, variable etc ..
- meanwhile the exiting sequence continues and brings down the
  streams and gdb.

I'll try to reproduce this on a Linux box(using GDBServer) this week and dig more.