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]
Other format: [Raw text]

Re: [mi] watchpoint-scope exec async command


On Mon, Mar 28, 2005 at 05:41:01PM -0500, Daniel Jacobowitz wrote:
> On Mon, Mar 28, 2005 at 05:56:19PM -0500, Bob Rossi wrote:
> >    (gdb) n
> >    Hardware watchpoint 2 deleted because the program has left the block
> >    in which its expression is valid.
> >    Segmentation fault
> > 
> > The crash only happens sometimes. Although when I run it over and over,
> > I will eventually get it.
> > 
> > Here is the problem I found,
> > 
> >    (gdb) n
> >    Hardware watchpoint 2 deleted because the program has left the block
> >    in which its expression is valid.
> >    ==26644== Invalid write of size 4
> >    ==26644==    at 0x80D9B32: insert_bp_location (breakpoint.c:1022)
> >    ==26644==    by 0x80D9EDA: insert_breakpoints (breakpoint.c:1151)
> >    ==26644==    by 0x8119620: proceed (infrun.c:774)
> 
> I envy you.  I can't get valgrind to work with GDB; once I try to run a
> child process, it falls over.

Yeah, I was thinking I could script valgrind through the GDB testsuite,
and report any memory leaks/memory corruption. This would probably be a
big task though ...

> > So, basically, I can't figure out why the breakpoint field
> > 'related_breakpoint' became in valid. I believe it was valid when the
> > breakpoint was created, since the memset is there. However, at some
> > point, it must have become invalid ...
> 
> The related breakpoint is supposed to be the scope breakpoint; I can't
> see how they could become unpaired.  You may want to run a debugger on
> GDB, using a watchpoint to see what changes it?

I've tried this, GDB didn't seem to think anyone access'd
b->related_breakpoint between the time it was set in watch_command_1 to
the time that valgrind gives the error in insert_bp_location.

My hunch is that b->related_breakpoint's memory was free'd and never set
to NULL. Is this possible? I don't think a watchpoint would pick that
up, would it?

Any other ideas? I've been debugging, but since I don't have a high
level overview of the data structures, I'm a little handicapped.

Bob Rossi


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