[Top][All Lists]
[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.