This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Possible pipe(2) bug


On Mon, Aug 09, 2010 at 03:00:03AM +0200, Bert Belder wrote:
>I think the pipe(2) implementation may have a bug. 
>
>The pipe function creates a pipe and returns two file descriptors
>(which are just numbers), one for reading and one for writing.  However
>sometimes (but rarely) two subsequent calls to the pipe function
>returns the same file descriptor twice.  That is normal when a file
>descriptor 'number' is re-used after being closed first, but otherwise
>it is wrong.  To demonstrate the problem I wrote a simple program
>(attached as test.c) that does the following:
>
>1. Create three pipes, so we get 6 file descriptors
>2. (dump the FD's we got)
>3. Close 3 of the 6 file descriptors
>4. (Dump the FD's that were closed)
>5. Repeat steps 1-4 a 100 times 
>
>The first three rounds give sound results:
>? ??0 opened: pipe1=(3, 4), pipe2=(5, 6), pipe3=(7, 8)
>? ??0 closed: pipe1[0]=3, pipe2[1]=6, pipe3[1]=8
>? ??1 opened: pipe1=(3, 6), pipe2=(8, 9), pipe3=(10, 11)
>? ??1 closed: pipe1[0]=3, pipe2[1]=9, pipe3[1]=11
>? ??2 opened: pipe1=(3, 9), pipe2=(11, 12), pipe3=(13, 14)
>? ??2 closed: pipe1[0]=3, pipe2[1]=12, pipe3[1]=14
>??? ...
>As can be seen the FD's that were closed are re-used next round. Perfectly fine.
>
>But then suddenly at round 94...
>??? 93 opened: pipe1=(3, 282), pipe2=(284, 285), pipe3=(286, 287)
>??? 93 closed: pipe1[0]=3, pipe2[1]=285, pipe3[1]=287
>??? 94 opened: pipe1=(3, 285), pipe2=(287, 288), pipe3=(287, 289) ?<- !!!!!!!!!!!!
>File descriptor 287 is issued twice! 
>
>I think this is a bug.  It actually causes problems under certain
>circumstances when running a Cygwin build of nodejs
>(http://nodejs.org).  Or am I just doing something stupid?

Nope.  It was a very long-standing Cygwin bug.  The error occurred when
Cygwin extended the size of its fd table.  When that happened the the
internal information for the fd of the [0] element to the pipe() call
would never be filled out.  If you attempted to use it you'd probably
get an EBADF.  And, since cygwin thought it wasn't used it would present
it to your program again.  It's hard to believe that this hasn't shown
up before.

This should be fixed in the next snapshot, which is building now.

Thanks for the test case.

cgf

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]