Re: RFA: implement "watch -location"

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Fri, 13 Aug 2010 20:25:14 +0200, Tom Tromey wrote:
> Jan> this patch has a regression (guessing due to -lmcheck) on
> 
> The bug was that watch_maybe_just_location did not check for arg==NULL.
> So, a plain "watch" crashed gdb.

There is still a crash:
(gdb) watch -location gdb_stdin
== Invalid read of size 4
==    at 0x6420E3: can_use_hardware_watchpoint (breakpoint.c:8295)
==    by 0x641AE2: watch_command_1 (breakpoint.c:8140)
==    by 0x642342: watch_maybe_just_location (breakpoint.c:8376)
==    by 0x64236C: watch_command (breakpoint.c:8382)
==    by 0x5F0B04: do_cfunc (cli-decode.c:67)
==    by 0x5F3B72: cmd_func (cli-decode.c:1771)
==    by 0x48A9ED: execute_command (top.c:422)
==  Address 0xcee60a0 is 0 bytes inside a block of size 144 free'd
==    at 0x4C25D72: free (vg_replace_malloc.c:325)
==    by 0x48E6D3: xfree (utils.c:1505)
==    by 0x6554CD: value_free (value.c:687)
==    by 0x655503: value_free_to_mark (value.c:701)
==    by 0x641950: watch_command_1 (breakpoint.c:8101)
==    by 0x642342: watch_maybe_just_location (breakpoint.c:8376)
==    by 0x64236C: watch_command (breakpoint.c:8382)
==    by 0x5F0B04: do_cfunc (cli-decode.c:67)
==    by 0x5F3B72: cmd_func (cli-decode.c:1771)
==    by 0x48A9ED: execute_command (top.c:422)

The problem is:
	release_value (val);
	value_free_to_mark (mark);
should also have some:
	val->next = NULL;
as later
	mem_cnt = can_use_hardware_watchpoint (val);
will otherwise jump into the stale value_next pointer.
Just it cannot be implemented this way due to:
	breakpoint.c:8101:10: error: dereferencing pointer to incomplete type

While trying to fix it one could simplify the code as since
	cc7cc38174cfc79e75ea92a00b48591f90c83ea5
	http://sourceware.org/ml/gdb-cvs/2009-11/msg00184.html

the result of can_use_hardware_watchpoint() mostly gets immediately dropped as
it all gets recalculated in update_watchpoint again.  Still
bp_read_watchpoint/bp_access_watchpoint are not checked in update_watchpoint
so one cannot just drop the can_use_hardware_watchpoint call from
watch_command_1.


Thanks,
Jan