Re: [mi] watchpoint-scope exec async command

[Bob Rossi <bob@brasko.net>]

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