From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11788 invoked by alias); 31 Mar 2005 00:49:29 -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 11717 invoked from network); 31 Mar 2005 00:49:10 -0000 Received: from unknown (HELO lakermmtao12.cox.net) (68.230.240.27) by sourceware.org with SMTP; 31 Mar 2005 00:49:10 -0000 Received: from white ([68.9.64.121]) by lakermmtao12.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050331004906.VKIU2476.lakermmtao12.cox.net@white>; Wed, 30 Mar 2005 19:49:06 -0500 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1DGomj-00004x-00; Wed, 30 Mar 2005 20:47:49 -0500 Date: Thu, 31 Mar 2005 00:49:00 -0000 From: Bob Rossi To: Eli Zaretskii Cc: GDB Subject: Re: [mi] watchpoint-scope exec async command Message-ID: <20050331014749.GA264@white> Mail-Followup-To: Eli Zaretskii , GDB References: <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> <01c534a6$Blat.v2.4$944e44a0@zahav.net.il> <20050329214414.GA3498@nevyn.them.org> <01c53564$Blat.v2.4$1da3c140@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c53564$Blat.v2.4$1da3c140@zahav.net.il> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-03/txt/msg00306.txt.bz2 On Wed, Mar 30, 2005 at 10:06:33PM +0200, Eli Zaretskii wrote: > > Date: Tue, 29 Mar 2005 16:44:14 -0500 > > From: Daniel Jacobowitz > > Cc: GDB > > > > If the scope breakpoint triggers, we delete it. From watch_command_1: > > /* Automatically delete the breakpoint when it hits. */ > > scope_breakpoint->disposition = disp_del; > > > > That's what's happening in this case. Then, shortly thereafter, the > > watchpoint triggers. That's when we detect that it has gone out of > > scope, and set it to delete at next stop; and we crash, because we > > already deleted the scope breakpoint when it was hit. > > I hoped to see this from Bob's tracebacks, but I only saw the first > part of what you describe: that the scope breakpoint is being deleted > after it triggers (not _when_, _after_: it is deleted by > breakpoint_auto_delete). > > Assuming that the watchpoint triggers after that, it is marked as > disp_del_at_next_stop, so it would be slated for deletion by the same > breakpoint_auto_delete function when it is called shortly after. This > is the part that I didn't see in Bob's session. I will assume that > things indeed happen like you say: that when we try to delete that > watchpoint, we crash when we access its scope breakpoint, which was > already deleted and freed. > > I think we have the following alternatives to fix this. First, we > could stop using scope breakpoints for hardware-assisted watchpoints. > (The scope breakpoint is not needed in this case, since they don't > slow down the executable, and because we have an independent facility > to detect that a hardware watchpoint went out of scope: that is the > code run by insert_bp_location and watchpoint_check which prints a > warning about the fact that the watchpoint went out of scope.) > Software watchpoints do need the scope breakpoint (to stop > single-stepping the inferior once the watchpoint goes out of scope), > and in that case Bob's testing demonstrates that the scope breakpoint > machinery works correctly. So we need to continue using scope > breakpoints for software watchpoints alone. > > If we don't arrange a scope breakpoint for a hardware watchpoint, we > won't hit the problem Bob reported. > > The second alternative is to treat scope breakpoints specially in > breakpoint_auto_delete: when we see a scope breakpoint that is marked > for deletion, we will have to find its watchpoint, and if that > watchpoint is a hardware watchpoint, we will have to delete that > watchpoint as well. > > I like the first alternative better, since it seems cleaner. The second alternative was my initial idea. However, I was just guessing, since I really know nothing about the code. The first approach seems good, I was just wondering if that would slow things down? Aren't hardware watchpoints must faster than software? If desired, I'd be interested in looking into either of these 2 fixes. However, I'll need a small amount of hand holding, so it might be faster for someone else to do it ... > As an aside, I'd ask Bob to run the same test program, but this time > use awatch instead of watch command. I'd be interested to hear if the > same problems (i.e. memory write into a freed block reported by > valgrind and an occasional crash) happen in that case as well. The > reason that I'm asking this is that we handle watch and rwatch/awatch > slightly differently, since the code that handles watch is run for > both software and hardware watchpoints. Funny you ask. When using hardware watchpoints, both rwatch and awatch result in the same bad behavior. However, when using software watchpoints, (gdb) rwatch param Expression cannot be implemented with read/access watchpoint. (gdb) awatch param Expression cannot be implemented with read/access watchpoint. (gdb) watch param Watchpoint 2: param (gdb) both rwatch and awatch are refused by GDB. > > I don't know if it still triggers today > > I think Bob's testing shows that it does, for the software > watchpoints. > > Did I help resolving this issue? But of course! Thanks for all the help, Bob Rossi