Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@codesourcery.com>
To: Tom Tromey <tromey@redhat.com>, Pedro Alves <palves@redhat.com>
Cc: <gdb-patches@sourceware.org>, Keith Seitz <keiths@redhat.com>
Subject: Re: [PATCH] remote: Fix a crash on longjmp breakpoint removal
Date: Wed, 07 Mar 2012 20:08:00 -0000	[thread overview]
Message-ID: <alpine.DEB.1.10.1203070448160.14492@tp.orcam.me.uk> (raw)
In-Reply-To: <m3vcpbjl79.fsf@fleche.redhat.com>

On Tue, 20 Dec 2011, Tom Tromey wrote:

> Maciej>  I have observed a crash, where GDB attempts to send a packet to
> Maciej> gdbserver after the remote target has already exited (and the
> Maciej> gdbserver process terminated) -- here's the tail of an example
> Maciej> remote session transcript:
> 
> Maciej>  I have tracked it down to remote_close calling
> Maciej> discard_all_inferiors, which in turn eventually calls
> Maciej> delete_thread_of_inferior, which calls
> Maciej> clear_thread_inferior_resources, which calls
> Maciej> delete_longjmp_breakpoint, which calls remote_remove_breakpoint,
> Maciej> which needs to send some packets to the remote target to get the
> Maciej> breakpoint removed.  But at this point the remote file
> Maciej> descriptor has already been closed; after a W00 stop reply
> Maciej> gdbserver does not expect any further input anyway.
> 
> You and Keith both came to the same diagnosis, but you have different
> patches:
> 
>     http://sourceware.org/ml/gdb-patches/2011-11/msg00212.html
> 
> ... our patch review delays seem to have bitten us this time.
> Or anyway bitten the two of you, sorry about that.
> 
> I am not sure which approach is better.  I don't think I know enough
> about remote.c to say.

 So I have finally got back to it and noticed that this:

http://sourceware.org/ml/gdb-patches/2012-01/msg00701.html

has already fixed the problem -- shall we close gdb/13333 then?  I think 
we should still add Keith's test case to cover any possible future 
breakage in this area -- the fix didn't include any.  I suggest that we 
retrofit the ChangeLog entry with a reference too.

  Maciej


  reply	other threads:[~2012-03-07 20:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-13 21:13 Maciej W. Rozycki
2011-12-20 16:00 ` Tom Tromey
2012-03-07 20:08   ` Maciej W. Rozycki [this message]
2012-03-07 20:47     ` Pedro Alves
2012-03-07 20:48       ` Keith Seitz
2012-03-10  2:55         ` Maciej W. Rozycki
2012-03-10  4:48           ` Keith Seitz
2012-03-10  5:11             ` Keith Seitz
2012-03-12 18:13               ` Pedro Alves

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=alpine.DEB.1.10.1203070448160.14492@tp.orcam.me.uk \
    --to=macro@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=keiths@redhat.com \
    --cc=palves@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