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