From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30009 invoked by alias); 8 Mar 2007 14:50:40 -0000 Received: (qmail 30001 invoked by uid 22791); 8 Mar 2007 14:50:40 -0000 X-Spam-Check-By: sourceware.org Received: from relay1.psi.neteu.net (HELO relay1.psi.neteu.net) (154.15.246.50) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 08 Mar 2007 14:50:38 +0000 Received: from [212.222.53.82] (helo=gg.pruftechnik.com) by relay1.psi.neteu.net with esmtp (Exim 4.65) (envelope-from ) id 1HPJwx-00050r-MB for gdb@sourceware.org; Thu, 08 Mar 2007 15:50:35 +0100 Received: from gg.pruftechnik.com (localhost [127.0.0.1]) by gg.pruftechnik.com (8.13.8/8.13.8) with ESMTP id l28EoZIt021287 for ; Thu, 8 Mar 2007 15:50:35 +0100 (CET) Received: (from localhost) by gg.pruftechnik.com (MSCAN) id 1/gg.pruftechnik.com/smtp-gw/mscan; Thu Mar 8 15:50:35 2007 In-Reply-To: <1173294544.22513.4.camel@localhost.localdomain> To: Michael Snyder Subject: Re: gdb continues when I want "next" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Markus.Grunwald@pruftechnik.com Date: Thu, 08 Mar 2007 14:50:00 -0000 Content-Type: text/plain; charset="US-ASCII" X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-03/txt/msg00126.txt.bz2 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