bug-gdb
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strongly suspected gdb bug.


From: Eli Zaretskii
Subject: Re: Strongly suspected gdb bug.
Date: Sun, 10 Apr 2005 08:05:06 +0300

> From: Casey Callaghan <address@hidden>
> Date: Fri, 8 Apr 2005 14:58:28 +0200
> 
> (gdb) watch *(Hidden *)0xbffff190
> Watchpoint 2: *(Bug::Hidden *) 3221221776

Here, GDB sets a software watchpoint on that address (because the
Hidden object is too large to watch it with x86 debug registers).

> (gdb) info break
> Num Type           Disp Enb Address    What
> 1   breakpoint     keep y   0x08048488 in main at gdb_bug.cpp:6
>         breakpoint already hit 1 time
> 2   watchpoint     keep y              *(Bug::Hidden *) 3221221776
> (gdb) run
> Starting program: /home/casey/Multicaster/Sender/a.out
> 
> (...seems to just stop here. I had to press ctrl-C to get any further 
> response...)

I think this is because the software watchpoint is still active, so
GDB single-steps the program and checks the watched region after each
instruction.  Can you verify that disabling the watchpoint before you
rerun the program solves the problem?

> Program received signal SIGINT, Interrupt.
> 0x40012a9a in ?? ()
> (gdb) bt
> #0  0x40012a9a in ?? ()
> #1  0x40007f4f in ?? ()
> #2  0x4005b5cf in ?? ()
> #3  0x4005b5cf in ?? ()
> #4  0x00000001 in ?? ()
> #5  0x00000020 in ?? ()
> #6  0x00000000 in ?? ()
> #7  0x00000000 in ?? ()

One possibility for the bogus backtrace is that GDB gets confused by
the startup code.  Try a newer GDB, perhaps it will behave better.  In
any case, I think disabling the watchpoint until the program gets to
your `main' function will work around the backtrace problem as well.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]