From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12643 invoked by alias); 28 Mar 2005 21:57:45 -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 12610 invoked from network); 28 Mar 2005 21:57:39 -0000 Received: from unknown (HELO lakermmtao12.cox.net) (68.230.240.27) by sourceware.org with SMTP; 28 Mar 2005 21:57:39 -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 <20050328215734.SLAN2476.lakermmtao12.cox.net@white>; Mon, 28 Mar 2005 16:57:34 -0500 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1DG39f-0000wd-00; Mon, 28 Mar 2005 17:56:19 -0500 Date: Mon, 28 Mar 2005 21:57:00 -0000 From: Bob Rossi To: Eli Zaretskii Cc: GDB Subject: Re: [mi] watchpoint-scope exec async command Message-ID: <20050328225619.GB3413@white> Mail-Followup-To: Eli Zaretskii , GDB References: <20050325161239.GA12231@white> <01c53207$Blat.v2.4$3def9b00@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c53207$Blat.v2.4$3def9b00@zahav.net.il> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-03/txt/msg00260.txt.bz2 On Sat, Mar 26, 2005 at 03:24:10PM +0200, Eli Zaretskii wrote: > > Date: Fri, 25 Mar 2005 11:12:39 -0500 > > From: Bob Rossi > > > > (gdb) > > -break-watch param > > ^done,wpt={number="2",exp="param"} > > (gdb) > > -exec-continue > > ^running > > (gdb) > > ~"Hardware watchpoint 2 deleted because the program has left the block \n" > > ~"in which its expression is valid.\n" > > *stopped,reason="exited",exit-code="02" > > (gdb) > > > > Is it just a bug that there is no 'watchpoint-scope' returned? > > I think it's a bug, yes: there's one instance in breakpoint.c > (specifically, in the function insert_bp_location) that uses > printf_filtered instead of the ui_* functions to produce the warning > about a watchpoint that went out of scope. I think it should use the > same code that is used by watchpoint_check to produce a similar > warning. OK, things have gotten much much worse. I've been studying watchpoints, and there behavior in GDB. This way, I could understand what the appropriate MI response should be. I came across this example, wpscope.c: int wpscope ( int param ) { return param+1; } int main(int argc, char **argv){ return wpscope ( argc ); } and ran these commands, $ ../gdb ./wpscope (gdb) b wpscope Breakpoint 1 at 0x8048357: file wpscope.c, line 2. (gdb) r Starting program: /home/bob/cvs/gdb/original/builddir/gdb/tmp/wpscope Breakpoint 1, wpscope (param=1) at wpscope.c:2 2 return param+1; (gdb) watch param Hardware watchpoint 2: param (gdb) fin Run till exit from #0 wpscope (param=1) at wpscope.c:2 main (argc=1, argv=0xbffffce4) at wpscope.c:7 7 } Value returned is $1 = 2 (gdb) n Hardware watchpoint 2 deleted because the program has left the block in which its expression is valid. Segmentation fault The crash only happens sometimes. Although when I run it over and over, I will eventually get it. Here is the problem I found, (gdb) n Hardware watchpoint 2 deleted because the program has left the block in which its expression is valid. ==26644== Invalid write of size 4 ==26644== at 0x80D9B32: insert_bp_location (breakpoint.c:1022) ==26644== by 0x80D9EDA: insert_breakpoints (breakpoint.c:1151) ==26644== by 0x8119620: proceed (infrun.c:774) ==26644== by 0x81165A7: step_1 (infcmd.c:698) ==26644== by 0x8116310: next_command (infcmd.c:595) ==26644== by 0x80BE17A: do_cfunc (cli-decode.c:57) ==26644== by 0x80C0675: cmd_func (cli-decode.c:1636) ==26644== by 0x80863D4: execute_command (top.c:442) ==26644== by 0x812A3EE: command_handler (event-top.c:508) ==26644== by 0x812ABA3: command_line_handler (event-top.c:793) ==26644== by 0x81E8E0B: rl_callback_read_char (callback.c:123) ==26644== by 0x8129B46: rl_callback_read_char_wrapper (event-top.c:174) ==26644== by 0x812A2B0: stdin_event_handler (event-top.c:424) ==26644== by 0x8129280: handle_file_event (event-loop.c:722) ==26644== by 0x8128B54: process_event (event-loop.c:335) ==26644== by 0x8128B9D: gdb_do_one_event (event-loop.c:372) ==26644== by 0x8125E40: catch_errors (exceptions.c:515) ==26644== by 0x80CE73B: tui_command_loop (tui-interp.c:151) ==26644== by 0x812635B: current_interp_command_loop (interps.c:278) ==26644== by 0x807BE62: captured_command_loop (main.c:92) So, basically, I can't figure out why the breakpoint field 'related_breakpoint' became in valid. I believe it was valid when the breakpoint was created, since the memset is there. However, at some point, it must have become invalid ... Any help would be appreciated. Thanks, Bob Rossi