From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27248 invoked by alias); 23 Dec 2008 00:49:29 -0000 Received: (qmail 27240 invoked by uid 22791); 23 Dec 2008 00:49:29 -0000 X-SWARE-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_83,KAM_MX,URI_HEX X-Spam-Check-By: sourceware.org Received: from mail.ecdeliverysystems.com (HELO mail.ecdeliverysystems.com) (216.27.67.202) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 23 Dec 2008 00:48:21 +0000 Received: from ECDS-CLT-MX1.ecdeliverysystems.com ([fe80::8d20:79c1:54db:18ec]) by ECDS-CLT-MX1.ecdeliverysystems.com ([fe80::8d20:79c1:54db:18ec%10]) with mapi; Mon, 22 Dec 2008 19:47:05 -0500 From: Allan Schrum To: "cygwin@cygwin.com" Date: Tue, 23 Dec 2008 00:49:00 -0000 Subject: RE: [1.7] Pipes intermittently lose data on Cygwin 1.7 Message-ID: <9BE596E8BDDC3443BF23B9678D03CC2928DF6E97@ECDS-CLT-MX1.ecdeliverysystems.com> References: <494CB77F.4040403@i12.com> <494D561E.9060607@i12.com> <20081222173111.GD27364@ednor.casa.cgf.cx> <494FDD16.4030903@i12.com> <20081222184701.GB23447@ednor.casa.cgf.cx> <494FF338.4020900@i12.com> In-Reply-To: <494FF338.4020900@i12.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes 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 X-SW-Source: 2008-12/txt/msg00566.txt.bz2 >=20 > >> Not yet. The bug is still present in the current snapshot > >> cygwin-inst-20081220.tar.bz2. Thanks for trying to fix it and for > >> responding to my post. >=20 >=20 > On 081222 10:47, Christopher Faylor wrote: > > Too bad. Since I can't duplicate the problem it will be difficult to > > fix it. >=20 > Have you tried running the examples I provided in my original post > (with foo =3D ~ 5MB text file) on a DOS shell (cmd.exe)? >=20 > I suggest running each example (in a DOS shell) at least 10 times, > comparing the file sizes of foo and bar each time. On my system, size > of bar < size of foo roughly 25-75% of the time. >=20 >=20 > > It would be helpful if you provided more information like the > cygcheck > > information requested in http://cygwin.com/problems.html. >=20 > Please see attached the output cygcheck -s -v -r > cygcheck.out. I ran > cygcheck on the current snapshot cygwin-inst-20081220.tar.bz2. >=20 > It would also > > be interesting to see the actual file sizes of foo and bar from your > > example. If they always vary in a consistent way that would be a > clue. >=20 > File sizes from latest test I ran (Example 1 of my original post) >=20 > tr \32 \0 < foo | tr \0 \32 > bar >=20 > on current snapshot cygwin-inst-20081220.tar.bz: >=20 > foo =3D 5,138,895 bytes > bar1 (runs 1-4, 6-7, 9-10) =3D 5,132,288 bytes > bar2 (runs 5 and 8) =3D 5,136,384 bytes >=20 > As you can see, there is some consistency. When I ran the above test 10 > consecutive times, there were only two types of output. On 8/10 runs, > bar was missing the same 6,607 (5,138,895 - 5,132,288) byte chunk. On > the remaining 2/10 runs, bar was missing the same 2,511 byte chunk. >=20 > As mentioned in my original post, the missing chunk is always at the > end (or beginning in the tac example) of bar. It's as if the pipe exits > too early, before all the data can make it through. >=20 > I'm attaching foo, bar1, and bar2 from the above example (compressed > with 7zip). >=20 > Greetings, > Lawrence A couple of observations that might trigger a clear thought. The numbers 5,= 132,288 and 5,138,895 are multiples of 4096. Assuming a standard 4096-byte = block, these sizes of "bar" are files of size 1253 and 1254 blocks. The fil= e "foo" only contains 1254 blocks with a remainder of 2511 bytes. Since the= last block, or sometimes the last two blocks, are not copied, this might i= mply some type of race condition that only appears on Lawrence's machine. C= hristopher's machine might be faster and not subject to this race condition. Lawrence: what is the hardware that your are running this test upon? What o= ther processes are running at the same time (e.g. CPU usage, I/O usage, etc= .)? It would appear the leading "tr" writes the file "foo" to the pipe, and clo= ses the pipe. This may cause the trailing "tr" to get a signal that it does= not handle well before it can complete the read from the pipe. If the hard= ware is too slow, or occupied, then perhaps it happens because of this rath= er than on other hardware which might be faster (or perhaps the reverse). Christopher: could you run the example in a mode where your computer is hea= vily loaded with other tasks? Only a suggestion. Regards, -Allan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/