From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3760 invoked by alias); 29 Mar 2005 21:33:33 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 3737 invoked from network); 29 Mar 2005 21:33:24 -0000 Received: from unknown (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org with SMTP; 29 Mar 2005 21:33:24 -0000 Received: from zaretski (IGLD-80-230-68-88.inter.net.il [80.230.68.88]) by romy.inter.net.il (MOS 3.5.6-GR) with ESMTP id AWD03916 (AUTH halo1); Tue, 29 Mar 2005 23:33:10 +0200 (IST) Date: Tue, 29 Mar 2005 21:33:00 -0000 From: "Eli Zaretskii" To: GDB Message-ID: <01c534a6$Blat.v2.4$944e44a0@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 In-reply-to: <20050329020123.GA7266@nevyn.them.org> (message from Daniel Jacobowitz on Mon, 28 Mar 2005 21:01:23 -0500) Subject: Re: [mi] watchpoint-scope exec async command Reply-to: Eli Zaretskii References: <20050325161239.GA12231@white> <01c53207$Blat.v2.4$3def9b00@zahav.net.il> <20050328225619.GB3413@white> <20050328224101.GA629@nevyn.them.org> <20050328235310.GA3699@white> <20050328230048.GA1697@nevyn.them.org> <20050329014203.GB3801@white> <20050329013634.GB6373@nevyn.them.org> <20050329024945.GC3957@white> <20050329020123.GA7266@nevyn.them.org> X-SW-Source: 2005-03/txt/msg00287.txt.bz2 [Sorry for a late response: I needed to refresh my memory of how the related code works.] > Date: Mon, 28 Mar 2005 21:01:23 -0500 > From: Daniel Jacobowitz > Cc: Eli Zaretskii > > We are deleting the scope breakpoint because the watchpoint has gone > out of scope Are you sure? Bob didn't show enough backtraces for me to be sure, but the one backtrace he did show seems to tell that we are deleting the scope breakpoint because it's marked either disp_del or disp_del_at_next_stop (and I'd like to know which of these two possibilities actually happens there), not because the watchpoint has gone out of scope (or at least not directly because of that). Bob, could you please show the backtraces at every place where you until now only posted the result of printing variables? Also, please put a breakpoint where GDB says a watchpoint has gone out of scope, and show a transcript of a session where we could see the sequence of the events: the watchpoint and/or scope breakpoint is hit, marked to be deleted ASAP, then actually deleted. > how did we fail to delete the watchpoint too? > > The answer seems to be that we use disp_del_at_next_stop if we hit the > _watchpoint_, but not if we hit the related breakpoint. When we delete > it we ought to be deleting its related breakpoint too (they point to > each other). But we don't. The only things we ever do with > related_breakpoints are set their dispositions. Sorry, I'm not sure I understand correctly what you are saying, because of the ambiguous use of "it" and "its". This sentence is the most ambiguous for me: > When we delete it we ought to be deleting its related breakpoint too > (they point to each other). Who is "it" here? If it's the watchpoint, then I don't understand your reasoning, because if the scope breakpoint rather than the watchpoint itself triggered, we don't delete anything. > That's presumably the bug. Probably, but I'd like to see more information (from Bob) to be sure. Let's not forget that software watchpoints also share some (most?) of the code used for hardware data-write watchpoints. I'm quite sure that the scope breakpoint was invented for software watchpoints, because hardware watchpoints simply don't need it: they incur no overhead if they are not deleted, as long as they are not hit; and once they are hit and we find them to be out of scope, we do TRT: mark both the watchpoint and its related breakpoint for deletion at next stop. (I suspect that we don't delete them right away due to some peculiarity of software watchpoints that are implemented by single-stepping the inferior.) Bob, could you also try the same program with a software watchpoint, and see if you hit the same bug or not? If the behavior is different, please show where the GDB execution thread goes a different way and how it avoids the crash. (Forcing software watchpoints might not be easy. One way, on a x86 machine, is to watch a region that is more than 16 bytes long. Another way is to build a hacked version of GDB that uses only software watchpoints.) > > Please look at the comments at breakpoint.c:6723 and breakpoint.c:1325. > > The comment at 6723 doesn't apply to this case, because that's bpstats > dangling a pointer; the breakpoint chain should never do this. ??? My interpretation of that comment is that a breakpoint/watchpoint that was already deleted should have its type set to bp_none, and in that case we don't delete it again. What am I missing?