From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12030 invoked by alias); 13 Jan 2006 17:35:43 -0000 Received: (qmail 12015 invoked by uid 22791); 13 Jan 2006 17:35:42 -0000 X-Spam-Check-By: sourceware.org Received: from lon-del-04.spheriq.net (HELO lon-del-04.spheriq.net) (195.46.50.101) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 13 Jan 2006 17:35:39 +0000 Received: from lon-out-02.spheriq.net ([195.46.50.130]) by lon-del-04.spheriq.net with ESMTP id k0DHZYZZ027109 for ; Fri, 13 Jan 2006 17:35:34 GMT Received: from lon-cus-01.spheriq.net (lon-cus-01.spheriq.net [195.46.50.37]) by lon-out-02.spheriq.net with ESMTP id k0DHZX9l014534 for ; Fri, 13 Jan 2006 17:35:33 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-01.spheriq.net with ESMTP id k0DHZV2N025782 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 13 Jan 2006 17:35:32 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id B8D54DA41 for ; Fri, 13 Jan 2006 17:35:30 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 85FA247544; Fri, 13 Jan 2006 17:38:56 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 13A607599B for ; Fri, 13 Jan 2006 17:38:55 +0000 (UTC) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 774F44754C for ; Fri, 13 Jan 2006 17:38:55 +0000 (GMT) Received: from [164.129.15.13] (terrorhawk.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.5.8-GR) with ESMTP id CHD18531 (AUTH stubbsa); Fri, 13 Jan 2006 17:35:28 GMT Message-ID: <43C7E466.9080703@st.com> Date: Fri, 13 Jan 2006 17:35:00 -0000 From: Andrew STUBBS User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrew STUBBS , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Disable thread specific breakpoints when thread dies References: <43723446.7000903@st.com> <20051113184515.GG3599@nevyn.them.org> <437875B0.4000007@st.com> <20051114155659.GA25717@nevyn.them.org> <437A19DE.6040905@st.com> <437B47A1.4040705@st.com> <20051117034811.GB3057@nevyn.them.org> <437CA66B.9060201@st.com> <20060112162659.GA16141@nevyn.them.org> In-Reply-To: <20060112162659.GA16141@nevyn.them.org> Content-Type: multipart/mixed; boundary="------------060200050807040200090302" X-O-Spoofed: Not Scanned X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 4.2.0 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00144.txt.bz2 This is a multi-part message in MIME format. --------------060200050807040200090302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 963 Daniel Jacobowitz wrote: >>> You shouldn't need to use the target method here. Does valid_thread_id >>> work? >>> >>> Also, please remember the space before opening parentheses. >> The thread still seems to have a valid ID after it has died. You can >> even do 'b 8 t 4' after the program has exited. It does give an error >> for threads which never existed though. > > Why does that happen? It is presumably a bug. > I have looked into this. The problem is that the threads are only deleted from the table when 'info threads' is used. The target method works because that queries the target, not GDB's internal state, and always gets the right answer (at least in our target interface). I am happy, therefore, that the attached patch, with valid_thread_id(), is correct, and will work once this other problem has been solved (or if the user types 'info threads'). OK to commit? I'll have a look for real problem next week probably. Andrew Stubbs --------------060200050807040200090302 Content-Type: text/plain; name="thread-break-3.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="thread-break-3.patch" Content-length: 888 2006-01-13 Andrew Stubbs * breakpoint.c (insert_breakpoints): Check that a thread exists before inserting thread specific breakpoints. Index: src/gdb/breakpoint.c =================================================================== --- src.orig/gdb/breakpoint.c 2006-01-03 18:23:49.000000000 +0000 +++ src/gdb/breakpoint.c 2006-01-13 16:34:50.000000000 +0000 @@ -1142,6 +1142,12 @@ insert_breakpoints (void) if (!breakpoint_enabled (b->owner)) continue; + /* There is no point inserting thread-specific breakpoints if the + thread no longer exists. */ + if (b->owner->thread != -1 + && !valid_thread_id (b->owner->thread)) + continue; + /* FIXME drow/2003-10-07: This code should be pushed elsewhere when hardware watchpoints are split into multiple loc breakpoints. */ if ((b->loc_type == bp_loc_hardware_watchpoint --------------060200050807040200090302--