gdb continues when I want "next"

gdb continues when I want "next"

[Markus.Grunwald]

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.


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 really need some help, since my colleagues are starting to kill me 
because thay can't debug...
One more note: The debugged program is compiled with gcc 2.95.4. Ancient, 
but we have no other choice at the moment... :(


P.S. Sorry to Daniel, I should have postet this to the list the first time 
...

Best regards

Markus Grunwald
Softwareentwicklung

PRÜFTECHNIK Condition Monitoring GmbH
Oskar-Messter-Straße 19-21
85737 Ismaning
www.pruftechnik.com
Tel: +49 (0)89 99616177
Fax: +49 (0)89 99616200

PRÜFTECHNIK Condition Monitoring GmbH
Sitz Ismaning / HRB 145655 München 
Geschäftsführer: Johann Lösl, Roland Schühle

Ein Unternehmen der PRÜFTECHNIK-Gruppe

Re: gdb continues when I want "next"

[Daniel Jacobowitz]

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

Re: gdb continues when I want "next"

[Michael Snyder]

> 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


Hang on -- are we forking a multi-threaded program?
Can't really do that, you know... or at least, it's
likely to be quite unpredictable unles the *only* thing
the fork-child does is call exec.

Re: gdb continues when I want "next"

[Markus.Grunwald]

Hello,

> > 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
 
> Hang on -- are we forking a multi-threaded program?

Well, not intentionally. But now that you asked, I used catch fork (which 
seems to work allthough the manual tells me it works only on HP-UX...) and 
it stopped several times. So, I think the answer is "yes".

The first halt of the catch fork gives me this, for example:

(gdb) catch fork
Catchpoint 1 (fork)
(gdb) run
[Thread debugging using libthread_db enabled]
[New Thread -1223350592 (LWP 25310)]
[Switching to Thread -1223350592 (LWP 25310)]

Catchpoint 1 (forked process 25313), 0xb7f9d410 in ?? ()
(gdb) bt
#0  0xb7f9d410 in ?? ()
#1  0x00000001 in ?? ()
#2  0x00000000 in ?? ()
#3  0xb72ad61e in strtold_l () from /lib/tls/i686/cmov/libc.so.6
#4  0xb7422add in system () from /lib/tls/i686/cmov/libpthread.so.0
#5  0x080f9827 in CPTApplication::SetupTmpDir (this=0x90f7260)
    at 
/home/gru/projects/vxp/branches/branch-0-2-00-X/Dafit_Code/dafit2/dafit2/CPTApplication.cpp:1676
#6  0x080f50a4 in CPTApplication::CPTApplication (this=0x90f7260, 
    nSuccess=@0xbf8a2ba4, nArgc=1, aszArgv=0xbf8a2c24)
    at 
/home/gru/projects/vxp/branches/branch-0-2-00-X/Dafit_Code/dafit2/dafit2/CPTApplication.cpp:467
#7  0x080fbafa in main (nArgs=1, aszArgs=0xbf8a2c24)
    at 
/home/gru/projects/vxp/branches/branch-0-2-00-X/Dafit_Code/dafit2/dafit2/main.cpp:55
(gdb) up 5
#5  0x080f9827 in CPTApplication::SetupTmpDir (this=0x90f7260)
1676            nReturn = system( oszRm.arg( GetCFTempDir()+"*" ).latin1() 
);
(gdb) info thread
* 1 Thread -1223350592 (LWP 25310)  0x080f9827 in 
CPTApplication::SetupTmpDir (
    this=0x90f7260)
    at 
/home/gru/projects/vxp/branches/branch-0-2-00-X/Dafit_Code/dafit2/dafit2/CPTApplication.cpp:1676

So there's just one thread here and the fork is caused by the "system" 
call. 

> Can't really do that, you know... or at least, it's
> likely to be quite unpredictable unles the *only* thing
> the fork-child does is call exec.
 
Could you explain this a bit further ? The system call surely isn't the 
only thing this thread does but it seems to work quite well - for now...
I found other examples, when we have more than one thread running when the 
catchpoint is reached, but in many cases the fork seems to be done by the 
qt library so that we don't really have any choice at this point ...

I have to admit that I don't understand why this shouldn't work ...

Thanks for your help,

Markus Grunwald

Re: gdb continues when I want "next"

[Daniel Jacobowitz]

On Thu, Mar 08, 2007 at 03:50:22PM +0100, Markus.Grunwald@pruftechnik.com wrote:
> > Can't really do that, you know... or at least, it's
> > likely to be quite unpredictable unles the *only* thing
> > the fork-child does is call exec.
>  
> Could you explain this a bit further ?

There was conventionally trouble, but POSIX gives it a pretty clear
meaning, and I believe both LinuxThreads and NPTL get it right
nowadays.

-- 
Daniel Jacobowitz
CodeSourcery

Re: gdb continues when I want "next"

[Markus.Grunwald]

Hello,

> > 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
 
> I have no idea.  Part of this sounds like GDB is confused by an
> excessive rate of forking and thread creation / destruction. 

We are using threads, of course. But I doubt there is an "excessive" rate 
of forking/threading ...

> I don't think we will be able to help you without a testcase we can
> use to reproduce your problems.

Hmm, that's bad. I can't give that code away, besides its size is 340MB 
... Isn't there anything that I could do myself when you give me some 
instructions, patches, whatever ?

(Sorry for sending this twice - I just hate lotus notes.)

Best regards

Markus Grunwald
Softwaredevelopment

Re: gdb continues when I want "next"

[Daniel Jacobowitz]

On Wed, Mar 07, 2007 at 12:20:15PM +0100, Markus.Grunwald@pruftechnik.com wrote:
> > I don't think we will be able to help you without a testcase we can
> > use to reproduce your problems.
> 
> Hmm, that's bad. I can't give that code away, besides its size is 340MB 
> ... Isn't there anything that I could do myself when you give me some 
> instructions, patches, whatever ?

You can certainly try to debug it.  But we can't really walk you
through it; there's no way to predict what's wrong.  The options under
"set debug" are a good place to start, especially set debug infrun.

-- 
Daniel Jacobowitz
CodeSourcery