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: List-Subscribe: List-Archive: List-Post: List-Help: , 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 To: "cygwin AT cygwin DOT com" Subject: Re: Regression (last snapshot) Date: Mon, 29 Jul 2019 18:55:59 +0000 Message-ID: References: <20190722164509 DOT GG21169 AT calimero DOT vinschen DOT de>

<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> <20190729134700 DOT GO11632 AT calimero DOT vinschen DOT de> <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 Content-Type: text/plain; charset="utf-8" Content-ID: <196A6FBCE970DA4BA7A4B443655540E2 AT namprd04 DOT prod DOT outlook DOT com> MIME-Version: 1.0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ksb2 AT cornell DOT edu X-IsSubscribed: yes Content-Transfer-Encoding: 8bit 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