This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
gdb oddity with disabled breakpoints
- From: Tom Tromey <tromey at redhat dot com>
- To: Gdb List <gdb at sources dot redhat dot com>
- Date: 04 Dec 2001 21:08:23 -0700
- Subject: gdb oddity with disabled breakpoints
- Reply-to: tromey at redhat dot com
I have a breakpoint set in a shared library. I put a condition on it,
then I disable it. Then I re-run the inferior. I get this:
(gdb) cond 3 start_PC == 135
(gdb) disa 3
(gdb) info b
Num Type Disp Enb Address What
1 breakpoint keep y 0x08048ae5 in main
at ../../../gcc/libjava/gij.cc:59
breakpoint already hit 1 time
2 breakpoint keep y 0x401bcb2c in verify_fail(char*, int)
at ../../../gcc/libjava/verify.cc:2675
breakpoint already hit 1 time
3 breakpoint keep n 0x4032f051 in _Jv_BytecodeVerifier::verify_instructions_0() at ../../../gcc/libjava/verify.cc:1836
stop only if this->start_PC == 135
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /x1/egcs/install/bin/gij loadem < QQ
Error in re-setting breakpoint 3:
No symbol "start_PC" in current context.
Error in re-setting breakpoint 3:
No symbol "start_PC" in current context.
Error in re-setting breakpoint 3:
No symbol "start_PC" in current context.
Error in re-setting breakpoint 3:
No symbol "start_PC" in current context.
Error in re-setting breakpoint 3:
No symbol "start_PC" in current context.
[New Thread 1024 (runnable)]
Error in re-setting breakpoint 3:
No symbol "start_PC" in current context.
Debugger segmentation fault
I don't have a stack trace for this failure (yet). I think I may have
reported this before but I don't recall.
My real question is not why gdb crashes, but why it apparently tries
to evaluate my breakpoint condition even though the breakpoint is
disabled. If I disable a breakpoint explicitly, I don't want gdb to
even try to handle it. At the very least I would expect these
messages to be suppressed.
Tom