Re: watchpoints inside 'commands'

[Edward Peschko <edwardp at excitehome dot net>]

> Sorry, I'm still missing something: the program _should_ stop when the
> watchpoint is hit, shouldn't it?  That's what a watchpoint is for: it
> stops the execution of the program being debugged when memory watched
> by a watchpoint is accessed.  What am I missing here?

But the point is that its not stopping when the watchpoint is hit; its stopping
WHEN THE WATCHPOINT IS DELETED BECAUSE IT GOES OUT OF SCOPE. Which is different,
and annoying. The proper behaviour should be that the watchpoint deletes itself
and the program continues running.

> > as soon as the scope changes inside of 'function', the program
> > breaks... It says 'watchpoint being deleted as the variable goes out
> > of scope'.
> 
> But this is exactly what you want: GDB just warns you about the fact
> that it deleted the watchpoint because it watches a variable on the
> stack that is no longer in use.  Why is that a problem?  The message
> doesn't mean that the program is broken, you should be able to
> continue it as usual.

But it *doesn't* continue as usual. It warns (which it shouldn't if I tell it
to be silent ) and then *stops*. It is transparent to the continue.

Say I'm running a program and 39,999 out of 40,000 times the variable key 
is allocated and deallocated successfully.

Now, I don't want to have the watchpoint stop all of those 40,000 times; I only
want it to stop if something else trounces the memory that I don't know about.

> You will have to find a repeatable scenario in which the same memory
> region is trashed, and then watch that memory region.
> 
> How do you find out where's the trashed region, if it changes from
> time to time?  Does it change because you modify your program,
> perhaps?

No, it changes because the program is threaded, and hence is asynchronous, and 
hence is not deterministic as to where it crashes. In addition, if I set up a 
watchpoint on a specific piece of memory, there are three points that the
watchpoint will break at:

	1) when the memory is initially allocated.
	2) when the memory is cleared/deleted.
	3) when the memory is trounced over.

Now, if it stops at #1, then the conditions of the program will have changed, 
and in all probability #3 will not occur at the same address because it has 
changed the state of the program before #3 occurs.

Ed