From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii To: edwardp@excitehome.net Cc: gdb@sources.redhat.com Subject: Re: watchpoints inside 'commands' Date: Fri, 06 Apr 2001 02:09:00 -0000 Message-id: <200104060909.FAA18637@indy.delorie.com> References: <20010405200028.A18474@excitehome.net> <20010405200525.A18623@excitehome.net> X-SW-Source: 2001-04/msg00047.html > Date: Thu, 5 Apr 2001 20:05:25 -0700 > From: Edward Peschko > > 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.