X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:date:message-id:references
	:in-reply-to:content-type:content-id:content-transfer-encoding
	:mime-version; q=dns; s=default; b=K23uq7BnQcZ89XiEpr1SZOQukbGVP
	xEnnWWc+XeC+Ibs2VPiNtPFmWR2BQq+1STNnm2iQKPC/X2UBUDriKwYGj3/8hgdf
	Jrp62wrY3CWyd9n2qBR6atcCiRizHVejZGZNmb4PTzZfxbYAz5+lC0O+OJYqQtVi
	5xUmPraTQRw8RY=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:date:message-id:references
	:in-reply-to:content-type:content-id:content-transfer-encoding
	:mime-version; s=default; bh=ujyVz0Zu8Tr+p5AOSq8JPNGy2Bw=; b=mcs
	tcoLIwwB4rquXLjMk+OWczvbp/POEwllsHdhAtS9DIfZU1e02GpSU6Pp6NEffqag
	MNvqCvvzfQDVfUgDMI9ewmxdoAk0ThpTPTYepml9thNTw9jCJJxDUjpC+0vYnLnJ
	xVhMrp31zlPsbdd4AhUSTCHWCHm8fZ9FN05sJbqc=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Spam-SWARE-Status:	No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=doubt, symptoms
X-HELO:	NAM02-CY1-obe.outbound.protection.outlook.com
ARC-Seal:	i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JD+HifECXijPHuIW+0cBzLI3KcheyDa8oFvR1WVzY6Eg52A3MWBgqZ1TPQSLm77g3ETC6PwwGjz/rz3xbPmM2Nc9rXVhA6L7YVtSk/s9Wnu8NbSeKDPsqXLbWWQ8C3TxtT0IMKfXPuqYyfzNDwu3SO0fIYoLCT2oFyjCcWSZIx1JBiUhU+RPRI+FggPozDrYuLLVZxO7K6fZZNXbPFV9sUR4UYE1V76baS8lauumL2pawajtIceanQ8OCZTcMHGyjsq6P3QcpcjUnRTjl83ldkFQqeIsbrk2zz1HX0BvaXYP4O/MOEWqxI/+2rR0Ns7QGXn3eC4gf8j5CH95JPmwVQ==
ARC-Message-Signature:	i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gQ86ajwbl3sO7WKGeGNVGfI1b03gsQYsFxRo7tYPUhA=; b=Fkmq7/R2nfgoFmjAU/AW8dGXZcZjYXBr5Hb+KCVkCt+XcsxHAWGjdLotMPk0xRFLsje2rD7iJfXgd0+8ymFWtuSLe/NUTIQxjjkunNbXdujy2/0+BV2jHblES1yFAUob7bE7u/Z48ooWq/7yMZmwo9Y2hm+BAD+lMcNq0ZDvX8dZhefvgRdHC7qU+oQcekBFt0xehRvSXg9af5kjbpZPjh2WHInL41cimn0wm5eXemGgiHRlC/yp+zmFIXsApHF93hocY8BYiXKEE152rgWTumML3nK8LapeoKW+IBNLhisxUwXylswIAlTXbIzDNMcKf8wmtkkVNIxNgvyqIj+ehg==
ARC-Authentication-Results:	i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cornell.edu;dmarc=pass action=none header.from=cornell.edu;dkim=pass header.d=cornell.edu;arc=none
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cornell.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gQ86ajwbl3sO7WKGeGNVGfI1b03gsQYsFxRo7tYPUhA=; b=P3D6oB5n80oLZsfLOn1AXwFYjVO629qvm7MvSDAgtrAbrP5juodA5pU6pgVjr/MneCNaOjUIXSziRjd0dOpjuPPz7yi2IcPWU0fV0QJSiJeMEcjVgtwxXUj0HJuO0j1fS2nMNljKsf7hn96FDdrGfR8EhqeQ+vWoXpezW+i/7O0=
From:	Ken Brown <kbrown AT cornell DOT edu>
To:	"cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject:	Re: Regression (last snapshot)
Date:	Mon, 29 Jul 2019 18:55:59 +0000
Message-ID:	<c5d01965-80b9-cece-54d2-f7462f84c0a2@cornell.edu>
References:	<20190722164509 DOT GG21169 AT calimero DOT vinschen DOT de> <eb8007691b20df0eb8032ca3d2fa445f AT smtp-cloud8 DOT xs4all DOT net> <b3b04db5-7f03-8281-f376-6cd10207ec01 AT cornell DOT edu> <4b59209a91e8384ec000e2724696791c AT smtp-cloud7 DOT xs4all DOT net> <935d8ce5-fd5c-3010-4664-bb2dc9b7ca2f AT cornell DOT edu> <20190729084552 DOT GL11632 AT calimero DOT vinschen DOT de> <eea273ca-f190-c91a-7892-9407bfcf4326 AT cornell DOT edu> <20190729134700 DOT GO11632 AT calimero DOT vinschen DOT de> <ced2750a-0a52-1396-b6c1-f4228116bde7 AT cornell DOT edu> <20190729152327 DOT GQ11632 AT calimero DOT vinschen DOT de> <20190729154049 DOT GR11632 AT calimero DOT vinschen DOT de>
In-Reply-To:	<20190729154049.GR11632@calimero.vinschen.de>
user-agent:	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
authentication-results:	spf=none (sender IP is ) smtp.mailfrom=kbrown AT cornell DOT edu;
x-ms-oob-tlc-oobclassifiers:	OLM:8882;
received-spf:	None (protection.outlook.com: cornell.edu does not designate permitted sender hosts)
x-ms-exchange-senderadcheck:	1
MIME-Version:	1.0
X-MS-Exchange-CrossTenant-mailboxtype:	HOSTED
X-MS-Exchange-CrossTenant-userprincipalname:	ksb2 AT cornell DOT edu
X-IsSubscribed:	yes
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id x6TIubXG032741

On 7/29/2019 11:40 AM, Corinna Vinschen wrote:
> On Jul 29 17:23, Corinna Vinschen wrote:
>> On Jul 29 14:26, Ken Brown wrote:
>>> On 7/29/2019 9:47 AM, Corinna Vinschen wrote:
>>>> On Jul 29 13:18, Ken Brown wrote:
>>>>> $ strace -o trace.out ls -lL <(grep bash .bashrc)
>>>>> ls: cannot access '/dev/fd/63': No such file or directory
>>>>
>>>> No, please run bash:
>>>>
>>>>     strace -o trace.out bash -c 'ls -lL <(grep bash .bashrc)'
>>>>
>>>> Otherwise there's no process actually creating the pipe, given the <()
>>>> expression is a bash expression.
>>>
>>> Yes, of course.  I should have realized this since it's exactly what I
>>> did under gdb.  Anyway, the result is the same as it was under gdb: If
>>> I run the command under strace, I don't see the broken pipe error.
>>>
>>> Is it possible that debugging causes an fd to the read end of the pipe
>>> to stay open longer, thereby preventing the error?
>>
>> The fact that you observe it sporadically points to a race condition.
>> Debugging serializes stuff usually running in parallel, potentially
>> eliminating the race.
> 
> Is there any chance this is a BLODA problem?

I doubt it.  I'm seeing this on two different computers, and I haven't seen any 
other symptoms suggesting BLODA.

>  If /dev/fd/63 doesn't
> exist in ls, it would mean ls didn't inherit the FIFO, which sounds
> very unlikely.

Actually I never saw an ls error saying /dev/fd/63 doesn't exist, except in my 
incorrect run of strace.

Here's the error that I can reproduce easily in xterm:

$ ls <(grep bash .bashrc)
/dev/fd/63
grep: write error: Broken pipe

This happens 98% of the time.  Notice that I used plain 'ls' rather than the 
original 'ls -lL'.  With the latter, I get the broken pipe error 60% of the time 
rather than 98%:

$ ls -lL <(grep bash .bashrc)
pr-------- 1 kbrown None 0 2019-07-29 14:46 /dev/fd/63
grep: write error: Broken pipe

What about the explanation I tried earlier, but perhaps not clearly: ls prints 
/dev/fd/63 and then exits, thereby closing the read end of the pipe, while grep 
(running asynchronously) hasn't finished writing to the write end of the pipe.

The fact that I get the broken pipe error more often with plain 'ls' than with 
'ls -lL' is consistent with that.  And the fact that I get no errors with 'cat 
<(grep bash .bashrc)' is also consistent with it, since cat doesn't exit until 
grep has finished writing.

On the other hand, this doesn't explain why I see the error only under xterm, 
nor does it explain why you can't reproduce it at all.

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -