Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


             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