Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm 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 Date: Sat, 14 Dec 2002 14:36:17 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: More pipe (and other) improvements in snapshot Message-ID: <20021214193617.GA1876@redhat.com> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <20021211041250 DOT GA31215 AT redhat DOT com> <094401c2a1da$954ab980$1d6cba8c AT sfdev3> <20021212165736 DOT GA14986 AT redhat DOT com> <3DF9F33C DOT 6060906 AT st DOT com> <20021214052744 DOT GA17108 AT redhat DOT com> <20021214053743 DOT GA20682 AT redhat DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021214053743.GA20682@redhat.com> User-Agent: Mutt/1.5.1i On Sat, Dec 14, 2002 at 12:37:43AM -0500, Christopher Faylor wrote: >On Sat, Dec 14, 2002 at 12:27:44AM -0500, Christopher Faylor wrote: >>On Fri, Dec 13, 2002 at 03:48:28PM +0100, Pavel Holejsovsky wrote: >>>nhv AT cape DOT com wrote: >>>>Christopher Faylor wrote: >>>>>On Thu, Dec 12, 2002 at 07:32:16AM -0500, Norman Vine wrote: >>>>>>Any 'tips' as to how to best debug this appreciated >>>>> >>>>>- Attach to the hung process with gdb and see where it is hung. >>>>> >>>>>- Provide cygcheck output. >>>>> >>>>>- Run under strace and see if you can infer where hangs or problems >>>>> are occurring. >>> >>>The hung process (sed) is actually not hung, but connected to stdin >>>instead of file. The root cause is that when config.status is processed >>>by bash, then sometimes `` construct forgets all output, causing >>>different generated file names to be empty, thus connecting sed to stdin >>>instead of some file. Following command line reproduces the bug for me: >>> >>>while true; do test "`echo foo`" = "foo" || echo failed; done >>> >>>When this command is run inside bash, then "failed" lines appear quite >>>regularly. The bug is reproducible only with /bin/bash, /bin/sh works >>>reliably. >> >>I meant to test the above before I made some more changes to cygwin >>to attempt to avoid data loss but I didn't get around to it. >> >>So, there is a snapshot up there which may or may not solve the problem. >>The above command doesn't die for me now, so I guess that's something. >> >>I'll check the prevous snapshot tomorrow to see if it actually fails for >>me. I've been a little sick for a couple of weeks now and attempting to >>stay with my "work on real job in the day and cygwin at night" scenario >>is not working too well. >> >>In the meantime, please try the current snapshot. It is probably >>slightly (but possibly unoticeably) slower but it should be very much >>less likely to lose data in a pipe. >> >>The latest snapshot also has some new inline assembly functions courtesy >>of some cygwin-developers (Gary R. Van Sickle and Thomas Pfaff) which >>might cause a little bit of a boost, too. > >Nevermind. I just tried the current snapshot on my NT4 machien and it >puked all over the place. > >I'll fix it tomorrow. Please avoid this snapshot until then. This should be fixed now. Please try the latest snapshot. Corinna also tracked down some thinkos in my handling of text mode reads which are fixed in this snapshot. Thanks, Corinna. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/