From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8269 invoked by alias); 7 Sep 2007 13:31:00 -0000 Received: (qmail 8262 invoked by uid 22791); 7 Sep 2007 13:30:59 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,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; Fri, 07 Sep 2007 13:30:55 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l87DU0L5007558; Fri, 7 Sep 2007 09:30:00 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l87DU0eo024915; Fri, 7 Sep 2007 09:30:00 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l87DTxCm030353; Fri, 7 Sep 2007 09:29:59 -0400 Message-ID: <46E15274.5020400@redhat.com> Date: Fri, 07 Sep 2007 13:31:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Kris Van Hees CC: frysk@sourceware.org Subject: Re: Patch for TearDownProcess References: <20070907022100.GK22263@oracle.com> In-Reply-To: <20070907022100.GK22263@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2007-q3/txt/msg00389.txt.bz2 Kris Van Hees wrote: > The attached patch *does* open the possibility that a stray process may remain > after tearDown() has been executed if e.g. a process termination causes another > process to be created, etc... However, that will not cause a testsuite hang. > It is also not expected to pose a problem with the further execution of the > testsuite (in fact, it is very likely to get cleaned up during the tearDown() > of the next test). > Unfortunately this isn't theoretical. On a slower f5 machine; this happens consistently; invalidating test results. Given the choices between a potential test-suite hang, and tear-down leaving waitpid events around, the decision was made in favor of the latter. That decision hasn't changed. Having the test run hang, is a lesser evil then the test-suite continuing but producing bogus results.. I restored the old behavior; and then added a timeout. It currently logs a message, I suspect it should abandon the test run, since the problem state hasn't gone away. Andrew