From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22630 invoked by alias); 29 Mar 2005 00:43:31 -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 22586 invoked from network); 29 Mar 2005 00:43:25 -0000 Received: from unknown (HELO lakermmtao05.cox.net) (68.230.240.34) by sourceware.org with SMTP; 29 Mar 2005 00:43:25 -0000 Received: from white ([68.9.64.121]) by lakermmtao05.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050329004317.RBBH3789.lakermmtao05.cox.net@white> for ; Mon, 28 Mar 2005 19:43:17 -0500 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1DG5k4-000111-00 for ; Mon, 28 Mar 2005 20:42:04 -0500 Date: Tue, 29 Mar 2005 00:43:00 -0000 From: Bob Rossi To: GDB Subject: Re: [mi] watchpoint-scope exec async command Message-ID: <20050329014203.GB3801@white> Mail-Followup-To: GDB 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050328230048.GA1697@nevyn.them.org> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-03/txt/msg00268.txt.bz2 > > My hunch is that b->related_breakpoint's memory was free'd and never set > > to NULL. Is this possible? I don't think a watchpoint would pick that > > up, would it? > > No, but valgrind would. Anyway, a breakpoint on delete_breakpoint > would probably catch this also. > > I can't imagine how that would happen though. Yeah, this appears to be what is happening. With a little help, we could probably squash this bug. breakpoint.c:5761 is where the related_breakpoint is allocated breakpoint.c:6721 is where the related_breakpoint is deleted breakpoint.c:1022 is where the problem occurs (just the next sucker to read/write the free'd related_breakpoint field) So, at breakpoint.c:5761 I do, (tgdb) p b $1 = (struct breakpoint *) 0x83b4878 (tgdb) p b->related_breakpoint $2 = (struct breakpoint *) 0x83b49d0 Then at breakpoint.c:6721, I print the breakpoint to be deleted (tgdb) p bpt $3 = (struct breakpoint *) 0x83b49d0 This is the related_breakpoint! at the end of breakpoint_delete I do (tgdb) p breakpoint_chain->next->next->next->next->next->next $30 = (struct breakpoint *) 0x83b4878 (tgdb) p breakpoint_chain->next->next->next->next->next->next->related_breakpoint $32 = (struct breakpoint *) 0x83b49d0 So the related_breakpoint was deleted, why other breakpoints still point to it. So, this shows exactly why GDB is crashing. The questions I have now is, Should the watchpoint be deleted when it is? Do we have to scan all the breakpoints to look at bp->related_breakpoint everytime a breakpoint is deleted? The backtrace is given below to explain why we are in delete_breakpoint. Thanks, Bob Rossi #0 delete_breakpoint (bpt=0x83b49d0) at ../../src/gdb/breakpoint.c:6895 #1 0x080e2888 in breakpoint_auto_delete (bs=0x8380a50) at ../../src/gdb/breakpoint.c:6702 #2 0x0811c8e3 in normal_stop () at ../../src/gdb/infrun.c:2999 #3 0x081196c2 in proceed (addr=4294967295, siggnal=TARGET_SIGNAL_DEFAULT, step=0) at ../../src/gdb/in frun.c:827 #4 0x0811741d in finish_command (arg=0x0, from_tty=1) at ../../src/gdb/infcmd.c:1280 #5 0x080be17b in do_cfunc (c=0x8337d60, args=0x0, from_tty=1) at ../../src/gdb/cli/cli-decode.c:57 #6 0x080c0676 in cmd_func (cmd=0x8337d60, args=0x0, from_tty=1) at ../../src/gdb/cli/cli-decode.c:163 6 #7 0x080863d5 in execute_command (p=0x831ff76 "", from_tty=1) at ../../src/gdb/top.c:442 #8 0x0812a3ef in command_handler (command=0x831ff70 "finish") at ../../src/gdb/event-top.c:508 #9 0x0812aba4 in command_line_handler (rl=0x8378f00 "x\2177\b") at ../../src/gdb/event-top.c:793 #10 0x081e8e0c in rl_callback_read_char () at ../../src/readline/callback.c:123 #11 0x08129b47 in rl_callback_read_char_wrapper (client_data=0x0) at ../../src/gdb/event-top.c:174 #12 0x0812a2b1 in stdin_event_handler (error=0, client_data=0x0) at ../../src/gdb/event-top.c:424 #13 0x08129281 in handle_file_event (event_file_desc=0) at ../../src/gdb/event-loop.c:722 #14 0x08128b55 in process_event () at ../../src/gdb/event-loop.c:335 #15 0x08128b9e in gdb_do_one_event (data=0x0) at ../../src/gdb/event-loop.c:372 #16 0x08125e41 in catch_errors (func=0x8128b6a , func_args=0x0, errstring=0x8286e7f "", mask=6) at ../../src/gdb/exceptions.c:515 #17 0x080ce73c in tui_command_loop (data=0x0) at ../../src/gdb/tui/tui-interp.c:151 #18 0x0812635c in current_interp_command_loop () at ../../src/gdb/interps.c:278 #19 0x0807be63 in captured_command_loop (data=0x0) at ../../src/gdb/main.c:92 #20 0x08125e41 in catch_errors (func=0x807be58 , func_args=0x0, errstring=0x826 c4dc "", mask=6) at ../../src/gdb/exceptions.c:515 #21 0x0807cd24 in captured_main (data=0xbffffae0) at ../../src/gdb/main.c:800 #22 0x08125e41 in catch_errors (func=0x807be97 , func_args=0xbffffae0, errstring=0x826c 4dc "", mask=6) at ../../src/gdb/exceptions.c:515 #23 0x0807cd5a in gdb_main (args=0xbffffae0) at ../../src/gdb/main.c:809 #24 0x0807be54 in main (argc=2, argv=0xbffffb54) at ../../src/gdb/gdb.c:35