Re: gdb continues when I want "next"

[Daniel Jacobowitz <drow@false.org>]

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