Re: gdb continues when I want "next"

[Markus.Grunwald@pruftechnik.com]

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