Re: watchpoints inside 'commands'

[Eli Zaretskii <eliz@delorie.com>]

> Date: Fri, 6 Apr 2001 11:19:45 -0700
> From: Edward Peschko <edwardp@excitehome.net>
> 
> On Fri, Apr 06, 2001 at 05:09:18AM -0400, Eli Zaretskii wrote:
> > > Date: Thu, 5 Apr 2001 20:05:25 -0700
> > > From: Edward Peschko <edwardp@excitehome.net>
> > > 
> > > Key *Object::getItem(Key key)
> > > {
> > >	return (Object::getItem(&key));  bug here.
> > > }
> > > 
> > > So. I tried the following:
> > > 
> > > b Object.cpp:12
> > > commands 1
> > > > silent
> > > > watch key._data[0]
> > > > continue
> > > 
> > > Unfortunately, this doesn't seem to work because, when the watchpoint is 
> > > eliminated, the program auto halts. Why?
> > 
> > What exactly do you mean by ``when the watchpoint is eliminated, the
> > program auto halts''?  Can you tell what commands do you type and what
> > does GDB print in response?
> 
> Basically, the program halts (stops) after the watchpoint is hit.

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?

> int function(char *string)
> {
>	# begin (line 15)
>	... (string shouldn't change but it does)
>	...
>	# end (line 40)
> }
>	
> then 'string' will have a different address every single time function is 
> called. I'd like the ability to track 'string' from line 15 to line 40, put 
> a hardware assisted watchpoint on it when line 15 is being reached,
> and letting go the watchpoint when line 40 is being reached.
> 
> 
> As it stands, if I say:
> 
> b 15
> commands
> > silent
> > watch string
> > continue
> 
> 
> 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.

> > > (ps -- this brings up another thing.. if you've got a heisenbug, how
> > > do you go about tracking it down? Say that another piece of your
> > > code (in another thread) is trashing your thread via an array bounds
> > > write (or some such thing) How can you track this down as being the
> > > cause?
> > 
> > I usually do that with hardware-assisted watchpoints on the memory
> > region that is being trashed.
> 
> but the memory region that is being trashed varies from time to time...

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?