From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20111 invoked by alias); 1 Apr 2008 22:30:58 -0000 Received: (qmail 20097 invoked by uid 22791); 1 Apr 2008 22:30:57 -0000 X-Spam-Check-By: sourceware.org Received: from host0.dyn.jankratochvil.net (HELO host0.dyn.jankratochvil.net) (89.250.240.59) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 01 Apr 2008 22:30:24 +0000 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.2/8.14.1) with ESMTP id m31MUC4m014696; Wed, 2 Apr 2008 00:30:12 +0200 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.2/8.14.2/Submit) id m31MUC6c014695; Wed, 2 Apr 2008 00:30:12 +0200 Date: Wed, 02 Apr 2008 00:01:00 -0000 From: Jan Kratochvil To: Doug Evans Cc: GDB Patches , mark.kettenis@xs4all.nl, Roland McGrath Subject: Re: [patch] Fix Linux attach to signalled/stopped processes Message-ID: <20080401223012.GA14076@host0.dyn.jankratochvil.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00030.txt.bz2 On Mon, 31 Mar 2008 21:18:51 +0200, Doug Evans wrote: > Was there any final resolution on this patch? > > http://sourceware.org/ml/gdb-patches/2007-06/msg00546.html > http://sourceware.org/ml/gdb-patches/2007-07/msg00003.html > > It doesn't seem to have gotten checked in but I couldn't find an > explanation. I don't see the problem on my fc8 box but I do see the > problem on an older one, so I'm guessing it was resolved to leave GDB > alone and leave the fix to the kernel. Is that correct? No, Fedora kernel ptrace(2)/waitpid(2) etc. syscalls (which use ptrace emulation running on top of the utrace subsystem) behave exactly the same as their kernel.org counterparts - except various bugs are being fixed by Roland McGrath in both of the implementations. The ptrace validity tests are at: http://sourceware.org/systemtap/wiki/utrace/tests The signaling problem needs to be handled carefully in GDB itself as the ptrace(2) API standard is unfriendly in these conditions: http://cvs.fedora.redhat.com/viewcvs/*checkout*/rpms/gdb/devel/gdb-6.7-bz233852-attach-signalled-fix.patch http://cvs.fedora.redhat.com/viewcvs/*checkout*/rpms/gdb/devel/gdb-6.7-bz233852-attach-signalled-test.patch (it applies OK, runtime not tested without the other Fedora patches there) Current/latest update of Fedora 8 already contains all the gdb changes (and kernel utrace compatibility fixes with kernel.org ptrace) to be in a good shape. Older Fedora kernel+gdb did have various bugs in this functionality. The GDB patch is fully compatible with the kernel.org (non-utrace) ptrace. The patch addresses these two issues: * Attachment to a process which is stopped (kill -SIGSTOP). * Attachment to a process with a rare race condition of having a signal currently being delivered - WAITPID returns there the signal which needs to be redelivered (otherwise it gets lost), upstream GDB assertion-fails as it will not get the expected SIGSTOP signal (which comes on next WAITPID from the kernel queue). Current patch still has one known problem that if we have a process already stopped and we attach to it by GDB with this patch it may start with the inferior state several instructions later than it was originally stopped. https://bugzilla.redhat.com/show_bug.cgi?id=244162#c17 It would be solvable if we would delay each attachment to a stopped process by some constant delay - such as 1 second - to give it a time for landing of all the possibly pending signals. OTOH probably better way to solve this flaw is to move from the ptrace(2) interface to the utrace interface (AFAIK with its userland part not defined so far) as the patch in its current form is insane. Also the more generic question may be what should happen if we try to attach a debugger to a SIGSTOPped process. Naive debugger will hang - this is right as the inferior is stopped - it should not run any operation, incl. its debugging. The condition whether the detached process (previously attached as stopped) should be left stopped or running is not intuitive there now, it is Red Hat patches backward compatible but IMO it should rather ask the user (with a default of leaving it stopped). This patch was developed with a lot of ptrace(2) info from Roland McGrath. Regards, Jan