Bug 68057 - fstat fails to return the correct size after a select on an fd that points to a pipe
fstat fails to return the correct size after a select on an fd that points to...
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-07-05 17:57 EDT by jay
Modified: 2007-04-18 12:43 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-07-05 17:58:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
gzipped tar file containing two c programs. (1.19 KB, application/octet-stream)
2002-07-05 17:58 EDT, jay
no flags Details

  None (edit)
Description jay 2002-07-05 17:57:09 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

Description of problem:
We do a non-timeout select on an fd pointing to a pipe. After select returns, 
we do an fstat on that fd to determine the number of bytes available on the 
pipe.  The st_size member of the structure contains 0.  This works properly on 
Red Hat Linux 6.2, Solaris 8, Irix 6.5, HP-UX 11.0, and Tru64 Unix 4.0f.  This 
problem makes it impossible to run our application on 7.2.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.cc -o parent parent.c
2.cc -o child child.c

Actual Results:  The "after select fstat reports" value is zero.

Expected Results:  The "after select fstat reports" value should be positive, 
as it is on all the other tested systems.

Additional info:
Comment 1 jay 2002-07-05 17:58:44 EDT
Created attachment 63884 [details]
gzipped tar file containing two c programs.
Comment 2 Arjan van de Ven 2002-07-06 04:47:45 EDT
Your application uses undefined behavior as per posix. Please fix it!
Older linux version accidentally had values in the stat fields that APPEARED to
be what others did, however these were the result of a rather serious bug in the

Having said that, for 7.2 we made an erratum kernel that deliberately puts this
random value back into the field for the case your application depends on.
However this is a temporary hack and it will go away in the future, esp when the
zero-copy pipes get implemented.

I'm closing this "fixed in errata" since we released several errata kernels with
the workaround that everyone should be using anyway due to the VERY important
security fixes in them.
Comment 3 jay 2002-07-08 12:32:09 EDT
Thanks for taking the time to look at this.  Two questions:
1.  What is the correct way to find out how much data is waiting on a pipe?
2.  Where do I get the errata kernel?

Dick Jay

Note You need to log in before you can comment on or make changes to this bug.