This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: watchpoints inside 'commands'


> 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?

> And can you set an 'intelligent' watchpoint, one that watches the value of a 
> variable *name* (not a variable instance) between point 'a' and point 'b' in 
> your code? This would be far more useful than the current behaviour - 
> currently, tracing one instance of a variable is useless if you've got a 
> function which creates and destroys tons of them...

I'm not sure I understand what you want, but it sounds like watching
the variable by its address instead of by its name should do the
trick.

> (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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]