public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [RFA/gdbserver] Unexpected EOF read from socket after inferior exits.
@ 2010-07-06 21:30 Joel Brobecker
  2010-07-06 22:30 ` Daniel Jacobowitz
  2010-07-20 21:14 ` Thomas Schwinge
  0 siblings, 2 replies; 7+ messages in thread
From: Joel Brobecker @ 2010-07-06 21:30 UTC (permalink / raw)
  To: gdb-patches; +Cc: Joel Brobecker

This is on GNU/Linux.

GDBserver does not exit properly when the inferior exits, as demonstrated
with any program using the procedure below:

   % gdbserver-head :4444 simple_main
   Process simple_main created; pid = 25681
   Listening on port 4444

Then, in another terminal, start GDB, connect to GDBserver, and run
the program to completion:

   % gdb-head simple_main
   (gdb) tar rem :4444
   (gdb) cont
   Continuing.

   Program exited normally.

Going back to the terminal where GDBserver is running, we see the following
output:

    Child exited with status 0
    readchar: Got EOF
    Remote side has terminated connection.  GDBserver will reopen the connection.
    Listening on port 4444

The problem is that we're missing a call to mourn_inferior.  As a result,
after we've handled the vCont packet, we fail to notice that there are
no process left to debug (target_running() returns true), and thus try
to continue reading from the remote socket.  However, since GDB just
disconnected after having received the "exit with status 0" reply to the
vCont request, the read triggers the EOF exception.

This patch fixes the problem by calling mourn_inferior after receiving
an inferior-exited event when in all-stop mode.  I know there are reasons
why we don't call the mourning code right after the wait like we used to.
It seems that, in that case, we can because we exit gdbserver shortly
after.

I really don't know whether this is the right approach or not - it feels
fragile to me.  For now, I took the lazy approach, but I noticed that
the resume-and-if-nonstop-send-ok-else-wait-send-reply code in both
handle_v_cont and myresume are identical and I think should be identical,
so perhaps we should factorize this code as well.

The problem is not all that serious in terms of the actual damage, but
I do feel that it's sufficiently visible and annoying that we should
have a fix for GDB 7.2.

gdb/ChangeLog:

        * server.c (handle_v_cont): Call mourn_inferior if process
        just exited.
        (myresume): Likewise.

Tested on x86_64-linux.

---
 gdb/gdbserver/server.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/gdb/gdbserver/server.c b/gdb/gdbserver/server.c
index 226d123..9125f0e 100644
--- a/gdb/gdbserver/server.c
+++ b/gdb/gdbserver/server.c
@@ -1779,6 +1779,10 @@ handle_v_cont (char *own_buf)
       last_ptid = mywait (minus_one_ptid, &last_status, 0, 1);
       prepare_resume_reply (own_buf, last_ptid, &last_status);
       disable_async_io ();
+
+      if (last_status.kind == TARGET_WAITKIND_EXITED
+          || last_status.kind == TARGET_WAITKIND_SIGNALLED)
+        mourn_inferior (find_process_pid (ptid_get_pid (last_ptid)));
     }
   return;
 
@@ -2079,6 +2083,10 @@ myresume (char *own_buf, int step, int sig)
       last_ptid = mywait (minus_one_ptid, &last_status, 0, 1);
       prepare_resume_reply (own_buf, last_ptid, &last_status);
       disable_async_io ();
+
+      if (last_status.kind == TARGET_WAITKIND_EXITED
+          || last_status.kind == TARGET_WAITKIND_SIGNALLED)
+        mourn_inferior (find_process_pid (ptid_get_pid (last_ptid)));
     }
 }
 
-- 
1.7.1

^ permalink raw reply	[flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-08-11 13:22 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-07-06 21:30 [RFA/gdbserver] Unexpected EOF read from socket after inferior exits Joel Brobecker
2010-07-06 22:30 ` Daniel Jacobowitz
2010-07-07 16:10   ` Joel Brobecker
2010-07-20 21:14 ` Thomas Schwinge
2010-07-21 20:49   ` Thomas Schwinge
2010-08-11 12:16   ` Thomas Schwinge
2010-08-11 13:22     ` Pedro Alves

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).