From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19385 invoked by alias); 28 Sep 2003 23:24:05 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 19377 invoked from network); 28 Sep 2003 23:24:05 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 28 Sep 2003 23:24:05 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 1A3ktV-0005QA-JJ; Sun, 28 Sep 2003 19:24:01 -0400 Date: Mon, 29 Sep 2003 02:21:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Michael Elizabeth Chastain , aurelien.chanudet@enst.fr, gdb@sources.redhat.com Subject: Re: process attaching gdb to itself Message-ID: <20030928232401.GA20802@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Michael Elizabeth Chastain , aurelien.chanudet@enst.fr, gdb@sources.redhat.com References: <200309282225.h8SMP9Rf026649@duracef.shout.net> <3F77622C.8090403@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F77622C.8090403@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-09/txt/msg00357.txt.bz2 On Sun, Sep 28, 2003 at 06:35:24PM -0400, Andrew Cagney wrote: > >Hello, > > > > char cmd [256]; > > sprintf (cmd, "gdb attach %d", getpid ()); > > system (cmd); > > > >'system' waits for the program that it calls to finish. > >Thus, your program is waiting for gdb to finish before it > >does anything. > > > >Try the appended program which uses raw fork/exec. > >It works for me on red hat linux 8, native i686-pc-linux-gnu. > > > >If you try to do this in production code then you are likely > >to run into a blizzard of race conditions, error cases, > >and signal handling problems. If you are doing this as a learning > >experience, that's great -- read up on 'man fork' and > >'man execlp', and check out a book on Linux systems programming. > > Is the kernel Linux? JeffJ and I just discovered that: > > $ sleep 1000 > ^Z > PID 1234 suspended > $ gdb sleep 1234 > ... > (gdb) > > works on BSD but fails on GNU/Linux. When doing an attach, BSD always > generates something for wait4 to consume. GNU/Linux does not, leaving > GDB stuck in wait4 :-( Yes, I've known about this problem for a long time. We've [I, Roland, a couple of other people I can't recall] talked about changing it and decided that, really, the current behavior makes more sense. It's not at all hard to make GDB work in the current system anyway. Just have to do it. It goes something like: - attach - wait4 WNOHANG, break if succeeds (optimistic, not necessary) - check in /proc to make sure the process is in a stopped state - If it was: - wait4 WNOHANG - If we get a status, then the process was running when we attached - If no status is available then the process was stopped when we attached - If it wasn't: - The process was running when we attached and hasn't stopped yet - wait4 without WNOHANG -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer