Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [PATCH, remote] Handle 'k' packet errors gracefully
@ 2013-04-22 19:03 Luis Machado
  2013-04-22 21:06 ` Pedro Alves
  0 siblings, 1 reply; 3+ messages in thread
From: Luis Machado @ 2013-04-22 19:03 UTC (permalink / raw)
  To: 'gdb-patches@sourceware.org'

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

Hi,

This is not a real problem with gdbserver, but other types of remote 
targets (other stubs, QEMU etc) may cut the connection abruptly since 
they are not required to reply to a 'k' (Kill) packet sent from GDB.

The following patch addresses any issues arising from such scenario, 
which leads to a GDB internal error due to an attempt to pop the target 
more than once. With the patch, this failure is handled gracefully.

As the ChangeLog suggests, i'm sending this on behalf of its original 
authors.

Luis

[-- Attachment #2: 0004-harden_kill.diff --]
[-- Type: text/x-patch, Size: 1832 bytes --]

2013-04-22  Pedro Alves <pedro@codesourcery.com>
            Maciej W. Rozycki <macro@codesourcery.com>

       gdb/
       * remote.c (remote_kill): Handle errors from the kill packet
       gracefully.

Index: gdb/remote.c
===================================================================
--- gdb.orig/remote.c	2013-04-22 14:13:25.512124202 +0200
+++ gdb/remote.c	2013-04-22 14:13:39.744123949 +0200
@@ -7714,12 +7714,36 @@ putpkt_for_catch_errors (void *arg)
 static void
 remote_kill (struct target_ops *ops)
 {
-  /* Use catch_errors so the user can quit from gdb even when we
+  struct gdb_exception ex;
+
+  /* Catch errors so the user can quit from gdb even when we
      aren't on speaking terms with the remote system.  */
-  catch_errors (putpkt_for_catch_errors, "k", "", RETURN_MASK_ERROR);
+  TRY_CATCH (ex, RETURN_MASK_ERROR)
+    {
+      putpkt ("k");
+    }
+  if (ex.reason < 0)
+    {
+      if (remote_desc == NULL)
+	{
+	  /* If we got an (EOF) error that caused the target
+	     to go away, then we're done, that's what we wanted.
+	     "k" is susceptible to cause a premature EOF, given
+	     that the remote server isn't actually required to
+	     reply to "k", and it can happen that it doesn't
+	     even get to reply ACK to the "k".  */
+	  return;
+	}
+
+	/* Otherwise, something went wrong.  We didn't actually kill
+	   the target.  Just propagate the exception, and let the
+	   user or higher layers decide what to do.  */
+	throw_exception (ex);
+    }
 
-  /* Don't wait for it to die.  I'm not really sure it matters whether
-     we do or not.  For the existing stubs, kill is a noop.  */
+  /* We've killed the remote end, we get to mourn it.  Since this is
+     target remote, single-process, mourning the inferior also
+     unpushes remote_ops.  */
   target_mourn_inferior ();
 }
 

^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-12-02 10:57 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-04-22 19:03 [PATCH, remote] Handle 'k' packet errors gracefully Luis Machado
2013-04-22 21:06 ` Pedro Alves
     [not found]   ` <alpine.DEB.1.10.1311301416410.21686@tp.orcam.me.uk>
2013-12-02 10:57     ` Pedro Alves

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox