This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: gdb continues when I want "next"
On Fri, Mar 02, 2007 at 02:44:14PM +0100, Markus.Grunwald@pruftechnik.com wrote:
> Hello,
>
> Using gdb 6.3 (where the version doesn't matter that much. I had the same
> trouble with 6.6) on an up to date debian etch I have (at least) two
> errors:
>
> 1) I set (exactly) one breakpoint. gdb stops on it. But more often then
> not when you issue a "next" or "finish" command, the program just
> continues without halt and breaks at this breakpoint agin. The program
> that is debugged is multi threaded.
> I _suspect_ that this only happens the first time that I debug the
> program: When the program ends and I type "run" for the second (and more)
> time, I can degub quite fine.
Anything like this sounds like a hardware or kernel problem, rather
than a GDB problem - either that or you're just getting lucky.
> 2) Conditions as above, but: Sometimes, I get this when reaching the
> breakpoint for the first time:
>
> Breakpoint 1, CPTLinearGraphic::CalculateLinLines (this=0x9251de0)
> at
> /home/gru/projects/vxp/branches/branch-0-2-10-X/Dafit_Code/drawdevices/CPTLinearGraphic.cpp:1640
> (gdb) n
> (gdb) n
> Detaching after fork from child process 29873.
> [Thread -1863816272 (LWP 29869) exited]
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> [Switching to Thread -1863816272 (LWP 29869)]
> 0xb7446891 in __nptl_death_event () from
> /lib/tls/i686/cmov/libpthread.so.0
> (gdb) fin
> Run till exit from #0 0xb7446891 in __nptl_death_event ()
> from /lib/tls/i686/cmov/libpthread.so.0
> 0x90e86490 in ?? ()
> (gdb)
> Run till exit from #0 0x90e86490 in ?? ()
> Warning:
> Cannot insert breakpoint 0.
> Error accessing memory address 0x0: Input/output error.
I have no idea. Part of this sounds like GDB is confused by an
excessive rate of forking and thread creation / destruction. After
that, I don't know where you've ended up.
I don't think we will be able to help you without a testcase we can
use to reproduce your problems.
> One more note: The debugged program is compiled with gcc 2.95.4. Ancient,
> but we have no other choice at the moment... :(
Expect very poor results for both C++ and optimized code if you're
using this compiler.
--
Daniel Jacobowitz
CodeSourcery