From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22647 invoked by alias); 14 Mar 2012 15:20:44 -0000 Received: (qmail 22627 invoked by uid 22791); 14 Mar 2012 15:20:43 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 14 Mar 2012 15:20:19 +0000 From: "palves at redhat dot com" To: gdb-prs@sourceware.org Subject: [Bug cli/13728] GDB crashes on catch exec -> detach Date: Wed, 14 Mar 2012 15:20:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: cli X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: palves at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org X-SW-Source: 2012-q1/txt/msg00423.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=13728 Pedro Alves changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |palves at redhat dot com --- Comment #3 from Pedro Alves 2012-03-14 15:20:17 UTC --- Yeah. This made me question whether we really want to continue processing the commands if the thread that hit the breakpoint is gone (detach/disconnect/kill/etc.). We similarly stop processing if the target is proceeded, which made me wonder about doing the same here, but in proceed case, we have extra complications, for example, related to ending up with more than one bpstat active for the same thread. So if we can make this work, it seems like we should try. Does that patch even run "valgrind free" ? It seems like you'd restore the bpstat into: inferior_thread ()->control.stop_bpstat But that thread has been deleted/free'd, along with its stop_bpstat. If we remove the bpstat temporarily out of the thread, as in: /* This pointer will iterate over the list of bpstat's. */ bs = *bsp; + *bsp = NULL; Then if something in the command list deletes a breakpoint that was in the bpstat, bpstat_remove_breakpoint_callback will not be able to find the bpstat, and we will end up a stale breakpoint pointer in the bpstat. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.