Re: watchpoints inside 'commands'

[Eli Zaretskii <eliz@delorie.com>]

> Date: Sat, 7 Apr 2001 17:33:41 -0700
> From: Edward Peschko <edwardp@excitehome.net>
> 
> > > 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.

Ah, okay, then how about setting a breakpoint near the exit from the
scope where the watchpoint is defined, and setting up the commands of
that breakpoint to silently delete the watchpoint and continue?  Would
that do what you want?

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

Can you get the trashing if some of the threads don't run?  It's
probably best to have the minimum number of threads that still
reproduce the problem.

Anyway, how many possible memory regions did you find to be trashed
until now?  If it is a relatively small number, watchpoints could
still help (you could watch all or most of them).

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

That's true, but you could handle this with watchpoint commands: they
could simply print their usual stuff and then continue.  Later you
could examine the session script and decide which of the breaks were
false alarms and which not.

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

What you describe sounds like uninitialized pointer somewhere, or some
other source of random addresses being poked.  (Are the regions that
get trashed really random, or do you have only a small set of possible
victims?)  If the address is really random, I'd suggest to think what
could be the source of such randomness.  A random address is not easy
to get by in most programs.