From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19805 invoked by alias); 29 Jul 2019 13:47:05 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 19797 invoked by uid 89); 29 Jul 2019 13:47:04 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-107.6 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GOOD_FROM_CORINNA_CYGWIN,NORMAL_HTTP_TO_IP,NUMERIC_HTTP_ADDR,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=UD:cygwin.com, cygwincom, cygwin.com X-HELO: mout.kundenserver.de Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.126.187) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 29 Jul 2019 13:47:03 +0000 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.167]) with ESMTPSA (Nemesis) id 1M1aQN-1hpcDf3KzD-0036lR for ; Mon, 29 Jul 2019 15:47:00 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 2B187A80410; Mon, 29 Jul 2019 15:47:00 +0200 (CEST) Date: Mon, 29 Jul 2019 13:47:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Regression (last snapshot) Message-ID: <20190729134700.GO11632@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <265a2749-95b6-38aa-a191-7913bfcc98b6@cornell.edu> <20190722152016.GE21169@calimero.vinschen.de> <20190722155340.GF21169@calimero.vinschen.de> <20190722164509.GG21169@calimero.vinschen.de> <4b59209a91e8384ec000e2724696791c@smtp-cloud7.xs4all.net> <935d8ce5-fd5c-3010-4664-bb2dc9b7ca2f@cornell.edu> <20190729084552.GL11632@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DXIF1lRUlMsbZ3S1" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-SW-Source: 2019-07/txt/msg00256.txt.bz2 --DXIF1lRUlMsbZ3S1 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2607 On Jul 29 13:18, Ken Brown wrote: > On 7/29/2019 4:45 AM, Corinna Vinschen wrote: > > On Jul 27 15:24, Ken Brown wrote: > >> On 7/27/2019 6:21 AM, Houder wrote: > >>> On Fri, 26 Jul 2019 22:12:43, Ken Brown wrote: > >>> > >>>> On 7/22/2019 2:47 PM, Houder wrote: > >>> > >>>>> The specific regression as reported, has gone. > >>>>> > >>>>> 64-@@ uname -a > >>>>> CYGWIN_NT-6.1 Seven 3.1.0s(0.339/5/3) 2019-07-22 16:43 x86_64 Cygwin > >>>>> 64-@@ ls -lL <(grep bash .bashrc) > >>>>> pr-------- 1 Henri None 0 Jul 22 20:36 /dev/fd/63 > >>>> > >>> Over all the behavior has simularity w/ the error reported by David K= arr: > >>> > >>> https://cygwin.com/ml/cygwin/2019-07/msg00150.html > >>> ( Piping input from subprocess loses track of temp file ) > >> [...] > >> Repeating this under the 20190722 or 20190725 snapshots gave slightly = worse > >> results (close to 500 errors). Using my own unoptimized build of cygw= in1.dll, > >> the error count went up to about 650. > >=20 > > I just tried this myself and I can't reproduce the problem. 1000 runs, > > no error. >=20 > Interesting. And you ran this under X11 in an xterm window? I didn't, but I just did and the result is the same, no errors. > >> I tried running under gdb, but I couldn't get grep to fail. More prec= isely, I > >> didn't see an error message from grep. Every run looked like this: > >> > >> $ gdb bash > >> GNU gdb (GDB) (Cygwin 8.2.1-1) 8.2.1 > >> [...] > >> (gdb) r -c 'ls -lL <(grep bash .bashrc)' > >> Starting program: /usr/bin/bash -c 'ls -lL <(grep bash .bashrc)' > >> [...] > >> pr-------- 1 kbrown None 0 2019-07-27 11:07 /dev/fd/63 > >> [...] > >> [Inferior 1 (process 21712) exited normally] > >> > >> It would be better to be able to debug ls and/or grep, but I don't kno= w how to > >> get to subprocesses in gdb. And I think I have to start with 'gdb bas= h' in > >> order for the process substitution to happen. > >=20 > > Yeah, subprocess debugging is a problem in GDB. Given how this works, > > you can at least take grep out of the picture. Bash is doing all the > > lifting, so it's just bash and ls. Did you try to reproduce this under > > strace? >=20 > Yes, but there I get an error (even under mintty) for a different reason: >=20 > $ strace -o trace.out ls -lL <(grep bash .bashrc)=20 > 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. Corinna --=20 Corinna Vinschen Cygwin Maintainer --DXIF1lRUlMsbZ3S1 Content-Type: application/pgp-signature; name="signature.asc" Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAl0++NQACgkQ9TYGna5E T6C1Rw/9FZY7OGRkd/S99/jQMaer4S0MPyhg41oeuAaCdNG/dlXCsF962ydP9Zoe tGU7fC4e1LXQQDsF6IOQWSL00oyHg5Wk9pw7+hLJQUai/3xO6ODmGmMTLOsrGFI1 Fk3WTP7XsHtsf51MI1ZLvbTxjL1i1AV7gVb571EI0JP97PpqI89oC9ET/Cz6JhbF yOl2OYp3hOyq4hVlFGKxmtFE95ootXmflWN1gMfEc8EKGiZZYDkwXUzqqAGavRyw R8D7Sd1xP8Apz1h7R7J7w1GgjefJNT1MkP6D3lVjLuRY1MKeE/hoh/fGr2r5lh+f yhrzBmw2lnMmBN0Wmn+kTUbAKwSM0a/4DiVQMLkgzpomO0Y9RRwyXXJiJqji8mHq 6sHEqd5FYcoR5gxeUbUHNQDHcnGviRZztLAWSN7qPK1Aub+9TRb4ZQWsF+Bw6dsv 3OLYKvx8TzDp40XxJaqdcQQUkpuYUWWdlM+LhT+4C1c/96QAms6Ed+lshH0CxRnL yy3s21KODaPEdWffybE9TKgpKaNrWgUNOsCv4/T1udPpu+iNEombbCNpbjHxHN/G ngvYITtzZcnm87t83wbMsDvwFQ6VZBl3w2QAR9XqMrCKzP+2iOlF41LPVrPwu76h ZSE4Hm2h7VLzbKNINkzt56FCkwafNWRLYaDMZIxATBm52oP/ME8= =lx5n -----END PGP SIGNATURE----- --DXIF1lRUlMsbZ3S1--