This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] remote: Fix a crash on longjmp breakpoint removal
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Tom Tromey <tromey at redhat dot com>, Pedro Alves <palves at redhat dot com>
- Cc: <gdb-patches at sourceware dot org>, Keith Seitz <keiths at redhat dot com>
- Date: Wed, 7 Mar 2012 20:08:16 +0000
- Subject: Re: [PATCH] remote: Fix a crash on longjmp breakpoint removal
- References: <alpine.DEB.1.10.1112131648050.5354@tp.orcam.me.uk> <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