From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17462 invoked by alias); 13 Dec 2011 21:10:00 -0000 Received: (qmail 17441 invoked by uid 22791); 13 Dec 2011 21:09:59 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,FROM_12LTRDOM,TW_GJ X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 13 Dec 2011 21:09:43 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1RaZba-0003A5-9P from Maciej_Rozycki@mentor.com ; Tue, 13 Dec 2011 13:09:42 -0800 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Dec 2011 13:09:41 -0800 Received: from [172.30.7.78] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Tue, 13 Dec 2011 21:09:39 +0000 Date: Tue, 13 Dec 2011 21:13:00 -0000 From: "Maciej W. Rozycki" To: CC: Tom Tromey Subject: [PATCH] remote: Fix a crash on longjmp breakpoint removal Message-ID: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-12/txt/msg00424.txt.bz2 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 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 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