From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27756 invoked by alias); 16 Jun 2008 12:22:34 -0000 Received: (qmail 27684 invoked by uid 22791); 16 Jun 2008 12:22:33 -0000 X-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 16 Jun 2008 12:21:59 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m5GCLirZ015537 for ; Mon, 16 Jun 2008 08:21:54 -0400 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5GCLinh021374 for ; Mon, 16 Jun 2008 08:21:44 -0400 Received: from localhost.localdomain (vpn-6-18.fab.redhat.com [10.33.6.18]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5GCLh1Y018218 for ; Mon, 16 Jun 2008 08:21:44 -0400 Message-ID: <48565AD5.8050902@redhat.com> Date: Mon, 16 Jun 2008 13:14:00 -0000 From: Phil Muldoon User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: frysk@sourceware.org Subject: vfork thoughts Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2008-q2/txt/msg00106.txt.bz2 I've bee reading about vfork challenges for the past week. Here are my thoughts. Mark when he fixed an issue related to breakpoints I think crystallized the issue with vfork in this thread: http://article.gmane.org/gmane.comp.monitoring.frysk.general/1072 While at first the issue of breakpoints might seem to be nothing to do with vfork(), it is very relevant. Literature suggests that the use of vfork for any purpose other than an immediate prelude to an exec call is not advisable. However, there could - and probably are - examples of where this is not the case. Also as detailed in Mark's email this makes the usage of breakpoints troublesome, as child and parent share memory. If we model vfork transparently though the fork observer then there is a danger of the user (be that an actual user, or an api call) assuming that the it is a true fork and not a vfork. Is it more sensible to model a completely separate set of observers to model vfork? This way, if there are breakpoints set in the child (and therefore the parent) we can uninstall them after the child execs. However this approach burdens the state machine with additional states that would essentially duplicate the fork states. Is the replication of code to deal with the vfork specific issues warranted here? If anyone has a real life use case for debugging a vfork scenario we could model, that would help also. Regards Phil