public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org, Oleg Nesterov <oleg@redhat.com>
Cc: Tom Tromey <tromey@redhat.com>
Subject: Re: [Oleg Nesterov] PATCH? gdb remote.c: readchar() should pop_target() if SERIAL_ERROR?
Date: Wed, 28 Jul 2010 19:49:00 -0000	[thread overview]
Message-ID: <201007282049.14873.pedro@codesourcery.com> (raw)
In-Reply-To: <m3fwzs1l8r.fsf@fleche.redhat.com>

Oleg Nesterov wrote:

>         (gdb) q
>         A debugging session is active.
> 
>                 Inferior 1 [Remote target] will be killed.
> 
>         Quit anyway? (y or n) y
>         putpkt: write failed: Broken pipe.
>         (gdb)
> 
> Not sure my analysis is correct, but I think that readchar() needs
> a fix. A read/recv from a socket doesn't necessarily returns EOF if
> the peer has closed the socket. 

> It can return sock->sk_err set by
> the previous send if the peer dies and sets sk->sk_shutdown.

Talking in terms of Linux kernel internals, eh?
Do note that you may actually be debugging with something
not tcp, say, a bog dumb serial line, and an error may happen
at any time, not just when quitting/killing the target
(although quitting is more prone to these kinds of issues, since
the 'k' packet doesn't actually require a reply).

> The patch merely adds pop_target(). The more sophisticates fix
> should probably continue the reading, sock->sk_err was cleared and
> the socket may have the packets which we could read.

I guess the idea must have been that the user would just retry
whatever failed.  But of course, that's prone for messing
things up too.  I'm thinking this should be rare enough under normal
conditions, and that it's not worth the hassle to do anything smarter
here.  We have no clue in what state the connection or the target
was left in.  We could claim that it's just better to reconnect
and refresh the whole debug state.

> --- gdb-7.1/gdb/remote.c~       2010-03-07 15:39:53.000000000 +0100
> +++ gdb-7.1/gdb/remote.c        2010-07-02 02:38:09.000000000 +0200
> @@ -6364,6 +6364,7 @@ readchar (int timeout)
>        error (_("Remote connection closed"));
>        /* no return */
>      case SERIAL_ERROR:
> +      pop_target ();
>        perror_with_name (_("Remote communication error"));
>        /* no return */
>      case SERIAL_TIMEOUT:

... thus, I have no problems with this.  Could you tweak the
string to say something like:

 "Remote communication error.  Target disconnected."

so that user is informed we're no longer talking to the
target?.

Okay with that change.

-- 
Pedro Alves

  parent reply	other threads:[~2010-07-28 19:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-09 19:57 Tom Tromey
2010-07-12 18:11 ` Michael Snyder
2010-07-27 21:55 ` Michael Snyder
2010-07-28 17:28   ` Tom Tromey
2010-07-28 19:49 ` Pedro Alves [this message]
2010-07-28 20:20   ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201007282049.14873.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=oleg@redhat.com \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).