This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [mi] watchpoint-scope exec async command
> > 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 <gdb_do_one_event>, 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 <captured_command_loop>, 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 <captured_main>, 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