From: "Maciej W. Rozycki" <macro@codesourcery.com>
To: <gdb-patches@sourceware.org>
Cc: Tom Tromey <tromey@redhat.com>
Subject: [PATCH] remote: Fix a crash on longjmp breakpoint removal
Date: Tue, 13 Dec 2011 21:13:00 -0000 [thread overview]
Message-ID: <alpine.DEB.1.10.1112131648050.5354@tp.orcam.me.uk> (raw)
Hi,
I have observed a crash, where GDB attempts to send a packet to gdbserver
after the remote target has already exited (and the gdbserver process
terminated) -- here's the tail of an example remote session transcript:
Sending packet: $vCont;c#a8...Packet received: W00
[Inferior 1 (Remote target) exited normally]
Sending packet: $Hg0#df...
This happens on the MIPS/Linux target while GDB is single-stepping with
the "step" command.
I have tracked it down to remote_close calling discard_all_inferiors,
which in turn eventually calls delete_thread_of_inferior, which calls
clear_thread_inferior_resources, which calls delete_longjmp_breakpoint,
which calls remote_remove_breakpoint, which needs to send some packets to
the remote target to get the breakpoint removed. But at this point the
remote file descriptor has already been closed; after a W00 stop reply
gdbserver does not expect any further input anyway.
I have looked through ChangeLogs and I believe this is a regression
caused by:
2010-12-09 Tom Tromey <tromey@redhat.com>
PR c++/9593:
* thread.c (clear_thread_inferior_resources): Call
delete_longjmp_breakpoint.
[...]
I have been able to get rid of the crash with the change below, no test
suite regressions on mips-linux-gnu (remote target). OK to apply?
2011-12-13 Maciej W. Rozycki <macro@codesourcery.com>
gdb/
* thread.c (clear_thread_inferior_resources): Don't call
delete_longjmp_breakpoint if there's no inferior.
Maciej
gdb-inferior-resources-crash.diff
Index: gdb-fsf-trunk-quilt/gdb/thread.c
===================================================================
--- gdb-fsf-trunk-quilt.orig/gdb/thread.c 2011-11-02 21:28:38.000000000 +0000
+++ gdb-fsf-trunk-quilt/gdb/thread.c 2011-12-13 19:42:25.805620748 +0000
@@ -119,7 +119,8 @@ clear_thread_inferior_resources (struct
do_all_intermediate_continuations_thread (tp, 1);
do_all_continuations_thread (tp, 1);
- delete_longjmp_breakpoint (tp->num);
+ if (!ptid_equal (inferior_ptid, null_ptid))
+ delete_longjmp_breakpoint (tp->num);
}
static void
next reply other threads:[~2011-12-13 21:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-13 21:13 Maciej W. Rozycki [this message]
2011-12-20 16:00 ` Tom Tromey
2012-03-07 20:08 ` Maciej W. Rozycki
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.1112131648050.5354@tp.orcam.me.uk \
--to=macro@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--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