Date: Wed, 13 Sep 2006 01:25:10 -0400
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: bash-3.1-7　BUG
Message-ID: <20060913052510.GB1256@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <091320060438 DOT 11140 DOT 45078B490008FD8600002B8422007610640A050E040D0C079D0A AT comcast DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <091320060438.11140.45078B490008FD8600002B8422007610640A050E040D0C079D0A@comcast.net>
User-Agent: Mutt/1.5.11
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On Wed, Sep 13, 2006 at 04:38:33AM +0000, Eric Blake wrote:
>> At any rate, thanks for narrowing down your application
>> to a smaller test case; I'll see what I can find with it.
>
>Here's something interesting in the strace:
>   30  518741 [main] bash 2084 readv: readv (255, 0x22C060, 1) blocking, sigcatchers 1
>   30  518771 [main] bash 2084 readv: no need to call ready_for_read
>   34  518805 [main] bash 2084 fhandler_base::read: read 0 bytes ()
>   29  518834 [main] bash 2084 fhandler_base::read: returning 135, text mode
>...
>   33 1682871 [main] bash 2084 fhandler_base::lseek: lseek (/home/eblake/text/zzz.sh, -103, 1)
>   32 1682903 [main] bash 2084 fhandler_base::lseek: setting file pointer to 429
>4967295 (high), 4294967193 (low)
>   34 1682937 [main] bash 2084 lseek64: 39 = lseek (255, -103, 1)
>
>Seems like a text mode lseek bug (no surprise there, since cgf
>predicted that there are still some corner cases).  The file is 142
>bytes, but has seven \r\n pairs, so the readv correctly returned 135
>characters read.  But the lseek back to the start of the third line
>temporarily set the file pointer to -3,

(actually -103, 4294967193U == -103)

>then settled on an offset of 39 (39 + 103 gives 142 bytes, as if in
>binary mode); the offset really should have been 32 characters in (byte
>34 is the start of the third line, so two \r would be skipped at that
>point).  I'm still not sure if it is bash's fault or cygwin's.  But the
>file definitely was read in text mode when it resided in a text mount.

Is bash assuming that it can read N characters and then subtract M
characters from the current position to get back to the beginning of a
line?  If so, hmm.  I guess this explains why it was reading a byte at a
time before.  It must be counting characters rather than calling lseek
to figure out where it is.

Fixing this is rarely as simple as just calling lseek, though, of
course.

cgf

--
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/