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

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

I realise that all the patch does is buy me a couple of secs, and it's
more a stopgap solution than a proper fix. How would you go about
ensuring events like Target TERMINATED or Target DISCONNECTED go through
reliably? 

> Questions:
> Did you have a PR for this ?
Not yet. 

> Is this happen for you only when doing remote/attach ?
Yes - we have gdbserver running on hardware.

> Is the abort/kill succesfull ?
When it gets through to the target successfully, then yes.

> Note, I'll happily apply corrections to head and 2.1 branch but for
the branch do not expect any release soon.
When are corrections likely to be applied to the head/2.1 branch?  

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?

thanks,
li-wei


-----Original Message-----
From: cdt-debug-dev-bounces@xxxxxxxxxxx
[mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Alain Magloire
Sent: 01 April 2005 18:19
To: cdt-patch@xxxxxxxxxxx
Cc: cdt-debug-dev@xxxxxxxxxxx
Subject: [cdt-debug-dev] Re: [cdt-patch] MISession terminate patch


> 
> doh! patch attached..
> 

Allright, but I'm not sure this will solve the problem.
The sequence of termination for the session is:

- Destroy the inferior(For the platform --> the DebugTarget):
	* if (the inferior is running || connected)
		send the abort/kill command for the inferior
	* send an event (Target TERMINATED)to the Debug platform about
the target being destroy.

- Remove the predicate
	* this will terminate the RxThread, TxThread and the Eventthread
	  on the there next iterations.

- Destroy the gdb session(for the platform --> The Launch session)
	* gdbProcess.destroy()

- Kill the RxThread, TxThread and EventThread explicitely if they are
still around.

- Fire and explicit (Session TERMINATED) event telling the sesion is
gone.

I can see a few things, if the EventThread was busy with pushing a lots
of events it may not have the chance to  process the (Targer TERMINATED)
event before being decommission.  So your patch may have buy the
EventThread a few seconds.


We could:

- Explicitely flush the event Queue, but it is probably useless since
  gdb is going down, there is no point to try update variables value and
all.

- Make sure that events like: Target TERMINATED or Target DISCONNECTED
goes through reliably,
  this could be done by not using the EventThread but rather
explicitely.
  The fact that we do not know when the EventThread will process the
event or when it will 
  go down can play tricks.


Questions:
Did you have a PR for this ?
Is this happen for you only when doing remote/attach ?
Is the abort/kill succesfull ?
Note, I'll happily apply corrections to head and 2.1 branch but for the
branch do not expect any release soon.



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