From stdcxx-dev-return-3479-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org Fri May 25 00:39:41 2007
Return-Path:
Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org
Received: (qmail 53475 invoked from network); 25 May 2007 00:39:40 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
by minotaur.apache.org with SMTP; 25 May 2007 00:39:40 -0000
Received: (qmail 97030 invoked by uid 500); 25 May 2007 00:39:41 -0000
Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org
Received: (qmail 97005 invoked by uid 500); 25 May 2007 00:39:41 -0000
Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: stdcxx-dev@incubator.apache.org
Delivered-To: mailing list stdcxx-dev@incubator.apache.org
Received: (qmail 96964 invoked by uid 99); 25 May 2007 00:39:41 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 May 2007 17:39:41 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: local policy)
Received: from [208.30.140.160] (HELO moroha.quovadx.com) (208.30.140.160)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 May 2007 17:39:35 -0700
Received: from qxvcexch01.ad.quovadx.com ([192.168.170.59])
by moroha.quovadx.com (8.13.6/8.13.6) with ESMTP id l4P0dAkC031786
for ; Fri, 25 May 2007 00:39:10 GMT
Received: from [10.70.3.113] ([10.70.3.113]) by qxvcexch01.ad.quovadx.com with Microsoft SMTPSVC(6.0.3790.1830);
Thu, 24 May 2007 18:37:54 -0600
Message-ID: <46563084.7010805@roguewave.com>
Date: Thu, 24 May 2007 18:40:36 -0600
From: Martin Sebor
Organization: Rogue Wave Software
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: infinite loop in exec
References: <4654A3FF.8020907@roguewave.com> <4654AB6B.2040909@roguewave.com> <4654B838.2020909@roguewave.com>
In-Reply-To: <4654B838.2020909@roguewave.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 May 2007 00:37:54.0918 (UTC) FILETIME=[EF20F060:01C79E64]
X-Virus-Checked: Checked by ClamAV on apache.org
I've looked into this problem some more and discovered that
the test actually does generate that much data due to what
looks like a bug in glibc. I've opened a bug report with
Red Hat and created an issue to track it on our end. See
https://issues.apache.org/jira/browse/STDCXX-428. I also
linked it to the infinite loop issue that Mark so speedily
opened yesterday:
https://issues.apache.org/jira/browse/STDCXX-426
Now that I know what the problem is I should be able to fix
the test so as to avoid this misbehavior.
That said, I think the problem illustrates that we should
also make exec more robust and less prone to getting into
trouble because of misbehaved tests. Maybe we should put
a cap on the amount of data tests are allowed to generate
before getting cut off? In addition, instead of reading
the test output one character at a time, exec should read
it line by line or in bigger chunks. I'll leave it to Andrew
to investigate which approach makes the most sense :)
Martin
Martin Sebor wrote:
> Andrew Black wrote:
>> Probably wouldn't hurt to open a jira for this, as I'm currently
>> running a sweep of results for our other products, and this may take a
>> little time to look into.
>
> Wow, looks like it's already done! (Thanks Mark!)
>
>>
>> Interestingly,
>> http://people.apache.org/~sebor/stdcxx/results/redhat_as-4.0-amd64-gcc-64b-3.4.6-12d-cfg-l.gz.txt
>> indicates that the trunk version of the 21.cwchar test produces the
>> following message when run under the exec utility:
>>> NAME STATUS WARN ASSERTS FAILED PERCNT
>>> USER SYS REAL
>>> 21.cwchar 0 0 169 10 94% 0.000
>>> 0.000 0.020
>
> Yeah, I've seen that too.
>
>>
>> However, if your working copy has changed as a result of work you've
>> been doing, this data is likely not relevant.
>
> That's a good point. I have reproduced the same behavior with
> a fresh sync to the head of trunk.
>
> Martin
>
>>
>> --Andrew Black
>>
>> Martin Sebor wrote:
>>> I'm running into an (almost?) infinite loop when running some
>>> of our tests under the exec utility on Linux (in a 12D build
>>> with gcc 3.4.6 on Red Hat Advanced Server 4, I haven't tried
>>> other configurations). The initial output of strace for one
>>> of the tests, 21.cwchar, is in the attached file. The test
>>> by itself runs fine to completion and doesn't produce any
>>> unusual output (no NULs).
>>>
>>> Andrew, when you have a chance, can you take a look at it?
>>> If that's not going to be soon let me know if I should open
>>> an issue.
>>>
>>> Martin
>