http://bugs.php.net/bug.php?id=45928
Christian Schneider wrote:
I had a quick look at this bug and found the problem to be in
Zend/zend_stream.c function zend_stream_fsize(): It usesfstat()to
determine the filesize which on MacOS X for pipes returns either 0 (my
interpretation: no data from the pipe ready yet) or a number up to 16384
(my interpretation: data from the pipe ready but the maximum buffer size
is 16k).I see several solutions but I'm not sure which is the desired one:
- return 0 (size unknown) if the file is a pipe (or socket, ...)
- return 0 if the file is not a regular file (or symlink, dir?)
- look into a way of determining EOF reached
As a quick test I changed
return buf.st_size;
in function zend_stream_fsize() to
return 0;
and cat 30k.php | php worked after that.I posted this to internals@php.net but did not get any reply so I'm not
sure how to proceed.
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
Hi,
On Tuesday 09 September 2008 14:39:05 Alexey Zakhlestin wrote:
http://bugs.php.net/bug.php?id=45928
Christian Schneider wrote:
I had a quick look at this bug and found the problem to be in
Zend/zend_stream.c function zend_stream_fsize(): It usesfstat()to
determine the filesize which on MacOS X for pipes returns either 0 (my
interpretation: no data from the pipe ready yet) or a number up to 16384
(my interpretation: data from the pipe ready but the maximum buffer size
is 16k).I see several solutions but I'm not sure which is the desired one:
- return 0 (size unknown) if the file is a pipe (or socket, ...)
- return 0 if the file is not a regular file (or symlink, dir?)
- look into a way of determining EOF reached
As a quick test I changed
return buf.st_size;
in function zend_stream_fsize() to
return 0;
and cat 30k.php | php worked after that.
It seems to be a good solution. zend_stream seems to already rely on size == 0
for non-regular files and falls back to something like "while (!feof){ read }"
in that case.
The following may (no MacOS X to test) fix the problem by returning 0 from
zend_stream_fsize() when the file descriptor is not a regular file:
http://arnaud.lb.s3.amazonaws.com/45928.patch
Regards,
Arnaud
Arnaud Le Blanc wrote:
The following may (no MacOS X to test) fix the problem by returning 0 from
zend_stream_fsize() when the file descriptor is not a regular file:
http://arnaud.lb.s3.amazonaws.com/45928.patch
Your patch:
+#ifdef S_ISREG
-
if (!S_ISREG(buf.st_mode)) { -
return 0; -
}
+#endif
might prevent mmap-ing symbolically linked files, I'll do a quick test
when I'm at home.
Not sure if we should also check for symbolic links (and what they point
to) or if that's overkill because the performance penalty is small
enough anyway.
Anyone from the core developers got an opinion here?
- Chris
Christian Schneider wrote:
Arnaud Le Blanc wrote:
The following may (no MacOS X to test) fix the problem by returning 0 from
zend_stream_fsize() when the file descriptor is not a regular file:
http://arnaud.lb.s3.amazonaws.com/45928.patchYour patch:
+#ifdef S_ISREG
if (!S_ISREG(buf.st_mode)) {return 0;}+#endif
might prevent mmap-ing symbolically linked files, I'll do a quick test
when I'm at home.
Not sure if we should also check for symbolic links (and what they point
to) or if that's overkill because the performance penalty is small
enough anyway.Anyone from the core developers got an opinion here?
- Chris
Check for symbolic links, it could potentially come up if you have a
common file.
The fsize code was written and tested on a Mac but I admit I was testing
with interactive mode and whole files. I can test this later on tonight
if I get time and if its good I'll commit it.
Scott
Hi,
On Tuesday 09 September 2008 17:35:54 Christian Schneider wrote:
Arnaud Le Blanc wrote:
The following may (no MacOS X to test) fix the problem by returning 0 from
zend_stream_fsize() when the file descriptor is not a regular file:
http://arnaud.lb.s3.amazonaws.com/45928.patchYour patch:
+#ifdef S_ISREG
if (!S_ISREG(buf.st_mode)) {return 0;}+#endif
might prevent mmap-ing symbolically linked files, I'll do a quick test
when I'm at home.
No, fstat() will resolve the link and stat the file the link points to. And I
believe script paths are fully resolved before being opened.
Anyway, given the fstat() Linux man page, its a bug to return st_size when the
file is not a regular file.
Not sure if we should also check for symbolic links (and what they point
to) or if that's overkill because the performance penalty is small
enough anyway.Anyone from the core developers got an opinion here?
- Chris
Regards,
Arnaud