#32861 [Bgs->Opn]: timeout is ignored in stream_select function
ID: 32861
User updated by: lew at mailduct dot com
Reported By: lew at mailduct dot com
-Status: Bogus
+Status: Open
Bug Type: Filesystem function related
Operating System: FreeBSD 4.11-REL
PHP Version: 4.3.10
New Comment:
After testing with the latest php5 release, this still has a problem.
Let me try to be more succinct in summarizing...
When operating with wrapper_type of 'plainfile' (such as when tailing
one or more files), the tv_sec and tv_usec (timeout) are ignored...
because stream_select insists on classifying FEOF as an important
event. While this may be true for a socket event (socket close, for
example... which is why we have socket_select instead), it is not true
for a plainfile event.
Ask yourself this question -- How would you make use of the 'timeout'
parameter when reading from a plainfile wrapper? It would never come
into play if FEOF awakens the stream_select call! The purpose of
stream_select is to let you multiplex streams... so you can WAIT for an
action to take place on a stream (or a timeout). If FEOF is allowed to
awaken the select (rather than waiting for a timeout or for data to
become available), then there's not much point to using that call...
You're forcing it to do [expensive] polling instead of relying on the
select() interrupt structure to do the work for you.
My second argument is this: Let's assume you insist FEOF should awaken
the select. If that's the case, then it still is not working
correctly... because if I *add data* to a file after the select
detected EOF, and then do a select again, it *still* thinks no data is
available (and that we're still at EOF even though we're not).
This is VERY broken.
Previous Comments:
--------------------
[2005-05-27 00:04:54] lew at mailduct dot com
I have now tested this using both PHP 4.3.11 and 5.0.4, and the bug
remains. My same prior notes apply. Please review.
--------------------
[2005-04-28 07:45:59] lew at mailduct dot com
I believe that under the OS and PHP version given in the headers of
this report, the stream timeout function is not working when used with
fgets as well. However, I will load the current PHP on the box and
test again, to ensure I provide you with accurate and complete
information and I'll open a new pr if necessary.
Let's close this one as Bogus.
[2005-04-28 00:35:16] [EMAIL PROTECTED]
>From the stream_select() manual page:
The streams listed in the read array will be watched to see if
characters become available for reading (more precisely, to see if a
read will not block - in particular, a stream resource is also ready on
end-of-file, in which case an fread() will return a zero length string).
[2005-04-28 00:05:08] [EMAIL PROTECTED]
Does this happen with PHP 4.3.11 or 5.0.4 ?
----------------
[2005-04-27 21:53:44] lew at mailduct dot com
Description:
Timeouts are ignored in stream_select. Instead, it always
returns with "1" as the number of streams affected, ignoring
any timeout seconds that are set.
This is true regardless of stream_set_blocking settings.
This may or may not be related to my reported FEOF problems:
pr #25649 (Sep 2003)
pr #32858 (Apr 2005)
Reproduce code:
---
$fp = fopen( '/var/log/maillog','r' );
## Tried both ways, got same results
#stream_set_blocking( $fp,TRUE );
#stream_set_blocking( $fp,FALSE );
$r = array( $fp );
while( TRUE ) {
$n = stream_select( $r,$w=NULL,$e=NULL,30 );
if( $n===FALSE ) echo "stream_select = FALSE\n";
else echo "stream_select = $n\n";
echo fgets($fp);
print( '.' );
}
Expected result:
Assuming no other program is writing to /var/log/maillog, I expect to
see a timeout condition every 30 seconds, as such:
stream_select = FALSE
Actual result:
--
Instead, I see iterations of:
stream_select = 1
as fast as the system can execute the loop.
--
Edit this bug report at http://bugs.php.net/?id=32861&edit=1
#32979 [Com]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979 Comment by: lew at mailduct dot com Reported By: mjpph at stardust dot fi Status: Assigned Bug Type: Network related Operating System: Linux (Fedora Core 3) PHP Version: 5CVS-2005-05-08 (dev) Assigned To: wez New Comment: wez -- the problems reported here are all due to a previously fixed bug which has crept back into PHP. It has to do with how the PHP library treats EOF under FreeBSD vs Linux. You worked on this problem previously... please take a look at the currently active Bug #32858 reported by me, as well as your prior fix in Bug #25649. Thanks Lew Payne Previous Comments: [2005-05-30 22:11:28] mjpph at stardust dot fi I haven't had problems with different kernels. Only the combination of x86_64, stream_socket_client() or stream_socket_server(), stream_select() and PHP OpenSSL-support seem to reproduce this every time. [2005-05-30 21:57:34] fox dot 69 at gmx dot net i experience a similar problem since the latest standard kernel update with yum (host.domain.com point to the main server IP) : http://host.domain.com";; $fp = fopen ($url,"r"); $buffer=fread($fp,8192); fclose($fp); echo $buffer; ?> booted with kernel-2.6.11-1.14_FC3 package: OK booted with kernel-2.6.11-1.27_FC3 package: NOT OK (timeout) NOTE: but only if "host.domain.com" point to the executing host itself - same with "localhost" - for all others it seem to be fine [2005-05-30 16:58:42] mjpph at stardust dot fi Also trying to compile valgrind on x86_64 results in: checking for a supported CPU... no (x86_64) configure: error: Unsupported host architecture. Sorry [2005-05-30 16:56:03] mjpph at stardust dot fi I could, but I get this: valgrind: Can only handle 32-bit executables On a 32bit executable and with openssl stream_select() worked ok. On a 64bit PHP executable it doesn't. [2005-05-30 16:33:24] [EMAIL PROTECTED] Can you now check it with valgrind, please? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/32979 -- Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32858 [NoF->Opn]: Bug #25649 has crept back into PHP - Improper feof() handling under FreeBSD
ID: 32858
User updated by: lew at mailduct dot com
Reported By: lew at mailduct dot com
-Status: No Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: FreeBSD 4.11-REL
PHP Version: 5.0.4, 4.3.10
Assigned To: wez
New Comment:
Bug is still present in latest snapshot of PHP.
Also... there seems to be at least one other bug report that is related
to this problem. See bug #32979. The problem is
directly related (and caused) by faulty stream_select and
stream_get_meta_data behaviour.
In summary:
1) stream_select does not properly detect the presence of additional
input data after it hits an EOF. Neither does stream_get_meta_data.
They both continue to return EOF even for a stream that has new data
(filestream, in my example).
2) stream_select does not properly honor its timeout parameter. If no
data is available, the call should WAIT for the timeout period to expire
before returning due to an EOF condition. Instead, it always returns
immediately with an EOF, making the timeout parameter pointless.
3) stream_select does not properly emulate the select() system call,
which would wait for a timeout if no more data were available (EOF)...
in case more data did become available.
Please let me know how else I can help. I'd like to get this recurring
problem resolved once and for all.
Previous Comments:
[2005-07-05 01:00:05] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2005-06-27 20:52:22] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-05-27 08:40:27] [EMAIL PROTECTED]
Assigning to Wez since he fixed it last time..
[2005-05-27 00:02:11] lew at mailduct dot com
I have now tested this using PHP 5.0.4 (cli), and the bug remains.
This bug was fixed by [EMAIL PROTECTED] on Sep 2003, but has now crept back
in to both versions 4 and 5 of PHP.
PHP is failing to clear the EOF indicator when reading a stream that
would otherwise BLOCK if read.
--- quote ([EMAIL PROTECTED]):
The PHP streams implementation uses the following logic
for determining the EOF status:
- after a read attempt, if no bytes were read OR
(a read error occurred and the error != EWOULDBLOCK)
--> set the EOF indicator
otherwise, clear the EOF indicator [1]
- after a successful fseek(), clear the EOF indicator.
[1] - this step was missing and has just been comitted to
the CVS.
The feof() function call works like this:
- if stream buffer has data, return false
- otherwise, return the EOF indicator flag.
---endquote
[2005-04-27 21:36:47] lew at mailduct dot com
Description:
In my prior bug report #25649 from September 2003, I pointed out a
serious bug in how PHP handles FEOF under FreeBSD. It was fixed by
[EMAIL PROTECTED] and committed.
This same problem (improper handling of feof() by PHP under FreeBSD)
has now crept into current 4.3.X versions of PHP...
Problem: Once set, the FEOF indicator is not properly cleared when
more data is appended to a file that is opened for read by a PHP
application.
Example: Suppose I want to "tail" a file using PHP. Once I hit the
EOF, I will no longer be able to read data from that file even when
another application appends to it. This is not the correct behaviour
for feof(), as illustrated by the prior fix done by [EMAIL PROTECTED]
Reproduce code:
---
--- program:
$fp = fopen( '/var/log/maillog','r' );
while( TRUE ) {
$r = array( $fp );
$n = stream_select( $r,$w=NULL,$e=NULL,30 );
if( $n ) {
echo fgets( $fp );
}
}
--- feeder:
echo "This is a test..." >> /var/log/maillog
Expected result:
For as long as PROGRAM is running, each time I run
FEEDER I expect to see PROGRAM output "This is a test..."
but it does not, because once EOF is reached, it is not
properly reset upon more data being appended to the file.
See pr #25649 for historical info...
Actual result:
--
PROGRAM will read the contents of /var/log/maillog until it
reaches EOF, and will not output anything else, even if new
data is appeneded to the file.
--
Edit this bug report at http://bugs.php.net/?id=32858&edit=1
#32861 [Bgs]: timeout is ignored in stream_select function
ID: 32861
User updated by: lew at mailduct dot com
Reported By: lew at mailduct dot com
Status: Bogus
Bug Type: Filesystem function related
Operating System: FreeBSD 4.11-REL
PHP Version: 4.3.10
New Comment:
I have now tested this using both PHP 4.3.11 and 5.0.4, and the bug
remains. My same prior notes apply. Please review.
Previous Comments:
[2005-04-28 07:45:59] lew at mailduct dot com
I believe that under the OS and PHP version given in the headers of
this report, the stream timeout function is not working when used with
fgets as well. However, I will load the current PHP on the box and
test again, to ensure I provide you with accurate and complete
information and I'll open a new pr if necessary.
Let's close this one as Bogus.
[2005-04-28 00:35:16] [EMAIL PROTECTED]
>From the stream_select() manual page:
The streams listed in the read array will be watched to see if
characters become available for reading (more precisely, to see if a
read will not block - in particular, a stream resource is also ready on
end-of-file, in which case an fread() will return a zero length string).
[2005-04-28 00:05:08] [EMAIL PROTECTED]
Does this happen with PHP 4.3.11 or 5.0.4 ?
[2005-04-27 21:53:44] lew at mailduct dot com
Description:
Timeouts are ignored in stream_select. Instead, it always
returns with "1" as the number of streams affected, ignoring
any timeout seconds that are set.
This is true regardless of stream_set_blocking settings.
This may or may not be related to my reported FEOF problems:
pr #25649 (Sep 2003)
pr #32858 (Apr 2005)
Reproduce code:
---
$fp = fopen( '/var/log/maillog','r' );
## Tried both ways, got same results
#stream_set_blocking( $fp,TRUE );
#stream_set_blocking( $fp,FALSE );
$r = array( $fp );
while( TRUE ) {
$n = stream_select( $r,$w=NULL,$e=NULL,30 );
if( $n===FALSE ) echo "stream_select = FALSE\n";
else echo "stream_select = $n\n";
echo fgets($fp);
print( '.' );
}
Expected result:
Assuming no other program is writing to /var/log/maillog, I expect to
see a timeout condition every 30 seconds, as such:
stream_select = FALSE
Actual result:
--
Instead, I see iterations of:
stream_select = 1
as fast as the system can execute the loop.
--
Edit this bug report at http://bugs.php.net/?id=32861&edit=1
#32858 [NoF->Opn]: Bug #25649 has crept back into PHP - Improper feof() handling under FreeBSD
ID: 32858
User updated by: lew at mailduct dot com
Reported By: lew at mailduct dot com
-Status: No Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: FreeBSD 4.11-REL
PHP Version: 4.3.10
New Comment:
I have now tested this using PHP 5.0.4 (cli), and the bug remains.
This bug was fixed by [EMAIL PROTECTED] on Sep 2003, but has now crept back
in to both versions 4 and 5 of PHP.
PHP is failing to clear the EOF indicator when reading a stream that
would otherwise BLOCK if read.
--- quote ([EMAIL PROTECTED]):
The PHP streams implementation uses the following logic
for determining the EOF status:
- after a read attempt, if no bytes were read OR
(a read error occurred and the error != EWOULDBLOCK)
--> set the EOF indicator
otherwise, clear the EOF indicator [1]
- after a successful fseek(), clear the EOF indicator.
[1] - this step was missing and has just been comitted to
the CVS.
The feof() function call works like this:
- if stream buffer has data, return false
- otherwise, return the EOF indicator flag.
---endquote
Previous Comments:
[2005-05-06 01:00:05] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2005-04-28 08:26:42] [EMAIL PROTECTED]
It wouldn't be the first time when something is magically fixed by
updating..and the changes might seem totally unrelated.
[2005-04-28 07:17:35] lew at mailduct dot com
I don't see any changes to the PHP feof library implementation between
4.3.10 and 4.3.11... shall I try it anyway and see if it magically
heals itself? I say this sarcastically because, if you look at
PR#25649 you'll see that I had to pull teeth just to get someone to
take this seriously. The default assumption is OE (Operator Error).
[2005-04-28 00:04:38] [EMAIL PROTECTED]
Have you tried PHP 4.3.11, the LATEST release..?
----
[2005-04-27 21:36:47] lew at mailduct dot com
Description:
In my prior bug report #25649 from September 2003, I pointed out a
serious bug in how PHP handles FEOF under FreeBSD. It was fixed by
[EMAIL PROTECTED] and committed.
This same problem (improper handling of feof() by PHP under FreeBSD)
has now crept into current 4.3.X versions of PHP...
Problem: Once set, the FEOF indicator is not properly cleared when
more data is appended to a file that is opened for read by a PHP
application.
Example: Suppose I want to "tail" a file using PHP. Once I hit the
EOF, I will no longer be able to read data from that file even when
another application appends to it. This is not the correct behaviour
for feof(), as illustrated by the prior fix done by [EMAIL PROTECTED]
Reproduce code:
---
--- program:
$fp = fopen( '/var/log/maillog','r' );
while( TRUE ) {
$r = array( $fp );
$n = stream_select( $r,$w=NULL,$e=NULL,30 );
if( $n ) {
echo fgets( $fp );
}
}
--- feeder:
echo "This is a test..." >> /var/log/maillog
Expected result:
For as long as PROGRAM is running, each time I run
FEEDER I expect to see PROGRAM output "This is a test..."
but it does not, because once EOF is reached, it is not
properly reset upon more data being appended to the file.
See pr #25649 for historical info...
Actual result:
--
PROGRAM will read the contents of /var/log/maillog until it
reaches EOF, and will not output anything else, even if new
data is appeneded to the file.
--
Edit this bug report at http://bugs.php.net/?id=32858&edit=1
#32861 [Bgs]: timeout is ignored in stream_select function
ID: 32861
User updated by: lew at mailduct dot com
Reported By: lew at mailduct dot com
Status: Bogus
Bug Type: Filesystem function related
Operating System: FreeBSD 4.11-REL
PHP Version: 4.3.10
New Comment:
I believe that under the OS and PHP version given in the headers of
this report, the stream timeout function is not working when used with
fgets as well. However, I will load the current PHP on the box and
test again, to ensure I provide you with accurate and complete
information and I'll open a new pr if necessary.
Let's close this one as Bogus.
Previous Comments:
[2005-04-28 00:35:16] [EMAIL PROTECTED]
>From the stream_select() manual page:
The streams listed in the read array will be watched to see if
characters become available for reading (more precisely, to see if a
read will not block - in particular, a stream resource is also ready on
end-of-file, in which case an fread() will return a zero length string).
[2005-04-28 00:05:08] [EMAIL PROTECTED]
Does this happen with PHP 4.3.11 or 5.0.4 ?
[2005-04-27 21:53:44] lew at mailduct dot com
Description:
Timeouts are ignored in stream_select. Instead, it always
returns with "1" as the number of streams affected, ignoring
any timeout seconds that are set.
This is true regardless of stream_set_blocking settings.
This may or may not be related to my reported FEOF problems:
pr #25649 (Sep 2003)
pr #32858 (Apr 2005)
Reproduce code:
---
$fp = fopen( '/var/log/maillog','r' );
## Tried both ways, got same results
#stream_set_blocking( $fp,TRUE );
#stream_set_blocking( $fp,FALSE );
$r = array( $fp );
while( TRUE ) {
$n = stream_select( $r,$w=NULL,$e=NULL,30 );
if( $n===FALSE ) echo "stream_select = FALSE\n";
else echo "stream_select = $n\n";
echo fgets($fp);
print( '.' );
}
Expected result:
Assuming no other program is writing to /var/log/maillog, I expect to
see a timeout condition every 30 seconds, as such:
stream_select = FALSE
Actual result:
--
Instead, I see iterations of:
stream_select = 1
as fast as the system can execute the loop.
--
Edit this bug report at http://bugs.php.net/?id=32861&edit=1
#32858 [Fbk->Opn]: Bug #25649 has crept back into PHP - Improper feof() handling under FreeBSD
ID: 32858
User updated by: lew at mailduct dot com
Reported By: lew at mailduct dot com
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: FreeBSD 4.11-REL
PHP Version: 4.3.10
New Comment:
I don't see any changes to the PHP feof library implementation between
4.3.10 and 4.3.11... shall I try it anyway and see if it magically
heals itself? I say this sarcastically because, if you look at
PR#25649 you'll see that I had to pull teeth just to get someone to
take this seriously. The default assumption is OE (Operator Error).
Previous Comments:
[2005-04-28 00:04:38] [EMAIL PROTECTED]
Have you tried PHP 4.3.11, the LATEST release..?
[2005-04-27 21:36:47] lew at mailduct dot com
Description:
In my prior bug report #25649 from September 2003, I pointed out a
serious bug in how PHP handles FEOF under FreeBSD. It was fixed by
[EMAIL PROTECTED] and committed.
This same problem (improper handling of feof() by PHP under FreeBSD)
has now crept into current 4.3.X versions of PHP...
Problem: Once set, the FEOF indicator is not properly cleared when
more data is appended to a file that is opened for read by a PHP
application.
Example: Suppose I want to "tail" a file using PHP. Once I hit the
EOF, I will no longer be able to read data from that file even when
another application appends to it. This is not the correct behaviour
for feof(), as illustrated by the prior fix done by [EMAIL PROTECTED]
Reproduce code:
---
--- program:
$fp = fopen( '/var/log/maillog','r' );
while( TRUE ) {
$r = array( $fp );
$n = stream_select( $r,$w=NULL,$e=NULL,30 );
if( $n ) {
echo fgets( $fp );
}
}
--- feeder:
echo "This is a test..." >> /var/log/maillog
Expected result:
For as long as PROGRAM is running, each time I run
FEEDER I expect to see PROGRAM output "This is a test..."
but it does not, because once EOF is reached, it is not
properly reset upon more data being appended to the file.
See pr #25649 for historical info...
Actual result:
--
PROGRAM will read the contents of /var/log/maillog until it
reaches EOF, and will not output anything else, even if new
data is appeneded to the file.
--
Edit this bug report at http://bugs.php.net/?id=32858&edit=1
#32861 [NEW]: timeout is ignored in stream_select function
From: lew at mailduct dot com
Operating system: FreeBSD 4.11-REL
PHP version: 4.3.10
PHP Bug Type: Filesystem function related
Bug description: timeout is ignored in stream_select function
Description:
Timeouts are ignored in stream_select. Instead, it always
returns with "1" as the number of streams affected, ignoring
any timeout seconds that are set.
This is true regardless of stream_set_blocking settings.
This may or may not be related to my reported FEOF problems:
pr #25649 (Sep 2003)
pr #32858 (Apr 2005)
Reproduce code:
---
$fp = fopen( '/var/log/maillog','r' );
## Tried both ways, got same results
#stream_set_blocking( $fp,TRUE );
#stream_set_blocking( $fp,FALSE );
$r = array( $fp );
while( TRUE ) {
$n = stream_select( $r,$w=NULL,$e=NULL,30 );
if( $n===FALSE ) echo "stream_select = FALSE\n";
else echo "stream_select = $n\n";
echo fgets($fp);
print( '.' );
}
Expected result:
Assuming no other program is writing to /var/log/maillog, I expect to see
a timeout condition every 30 seconds, as such:
stream_select = FALSE
Actual result:
--
Instead, I see iterations of:
stream_select = 1
as fast as the system can execute the loop.
--
Edit bug report at http://bugs.php.net/?id=32861&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32861&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32861&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32861&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32861&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32861&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32861&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32861&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32861&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32861&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32861&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32861&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32861&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32861&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32861&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32861&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32861&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32861&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32861&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32861&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32861&r=mysqlcfg
#32858 [NEW]: Bug #25649 has crept back into PHP - Improper feof() handling under FreeBSD
From: lew at mailduct dot com
Operating system: FreeBSD 4.11-REL
PHP version: 4.3.10
PHP Bug Type: Filesystem function related
Bug description: Bug #25649 has crept back into PHP - Improper feof() handling
under FreeBSD
Description:
In my prior bug report #25649 from September 2003, I pointed out a serious
bug in how PHP handles FEOF under FreeBSD. It was fixed by [EMAIL PROTECTED]
and
committed.
This same problem (improper handling of feof() by PHP under FreeBSD) has
now crept into current 4.3.X versions of PHP...
Problem: Once set, the FEOF indicator is not properly cleared when more
data is appended to a file that is opened for read by a PHP application.
Example: Suppose I want to "tail" a file using PHP. Once I hit the EOF,
I will no longer be able to read data from that file even when another
application appends to it. This is not the correct behaviour for feof(),
as illustrated by the prior fix done by [EMAIL PROTECTED]
Reproduce code:
---
--- program:
$fp = fopen( '/var/log/maillog','r' );
while( TRUE ) {
$r = array( $fp );
$n = stream_select( $r,$w=NULL,$e=NULL,30 );
if( $n ) {
echo fgets( $fp );
}
}
--- feeder:
echo "This is a test..." >> /var/log/maillog
Expected result:
For as long as PROGRAM is running, each time I run
FEEDER I expect to see PROGRAM output "This is a test..."
but it does not, because once EOF is reached, it is not
properly reset upon more data being appended to the file.
See pr #25649 for historical info...
Actual result:
--
PROGRAM will read the contents of /var/log/maillog until it
reaches EOF, and will not output anything else, even if new
data is appeneded to the file.
--
Edit bug report at http://bugs.php.net/?id=32858&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32858&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32858&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32858&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32858&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32858&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32858&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32858&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32858&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32858&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32858&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32858&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32858&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32858&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32858&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32858&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32858&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32858&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32858&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32858&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32858&r=mysqlcfg
#20548 [Com]: Decrement ("$x[$y]--") doesn't work on uninitiated variable
ID: 20548 Comment by: lew at mailduct dot com Reported By: prgallier at yahoo dot com Status: Wont fix Bug Type: Scripting Engine problem Operating System: Linux 2.4 PHP Version: 4.3.2-dev New Comment: "IMO, using unitialized variables should cause a FATAL error. Just initialize the variables you use." You miss the point. This is not about uninitialized variables. It is about a GROSS difference between how the increment and decrement operators work! Either *both* operations should fail with uninitialized variables (for consistency and sanity), or *both* operations should succeed (again, for the same reason). By simply saying, "initialize your variables" you avoid looking at the underlying problem and instead apply a band-aid. Band-aids are not a good thing... they come back to bite you later. If "plus" works a certain way, you'd expect "minus" to work the same (meaning, within the same framework of rules). All we are saying is, make them consistent! Previous Comments: [2003-09-27 20:01:38] prgallier at yahoo dot com There are plenty of workarounds, but the problem is the lack of consistency. Either you can or you can't use uninitialized variables. If you can use $test[0]++ you should be able to use $test[0]-- as well (no, I don't think they should drop the ability to use direct increments/decrements). [2003-09-27 16:47:47] [EMAIL PROTECTED] IMO, using unitialized variables should cause a FATAL error. Just initialize the variables you use. ---------------- [2003-09-27 14:38:53] lew at mailduct dot com PHP 4.3.3 on FreeBSD 4.8-RELEASE: ---------------- [2003-09-27 14:36:59] lew at mailduct dot com This is a GROSS inconsistency in how the increment/decrement operators work, and one that coders are likely to stumble upon the hard way. Please study the effect of fixing this, at the expense of breaking a long-time quirk in BC. Breaking a quirk, and documenting it on the BC page, is better than maintaining a GROSS inconsistency in one of the basic language construct operators! Please fix this! [2003-08-03 12:57:49] [EMAIL PROTECTED] This is a valid bug, however a fix would be a BC break that would result in a beahviour change that was in place since 3.0 days. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20548 -- Edit this bug report at http://bugs.php.net/?id=20548&edit=1
#20548 [Com]: Decrement ("$x[$y]--") doesn't work on uninitiated variable
ID: 20548 Comment by: lew at mailduct dot com Reported By: prgallier at yahoo dot com Status: Wont fix Bug Type: Scripting Engine problem Operating System: Linux 2.4 PHP Version: 4.3.2-dev New Comment: PHP 4.3.3 on FreeBSD 4.8-RELEASE: Previous Comments: [2003-09-27 14:36:59] lew at mailduct dot com This is a GROSS inconsistency in how the increment/decrement operators work, and one that coders are likely to stumble upon the hard way. Please study the effect of fixing this, at the expense of breaking a long-time quirk in BC. Breaking a quirk, and documenting it on the BC page, is better than maintaining a GROSS inconsistency in one of the basic language construct operators! Please fix this! [2003-08-03 12:57:49] [EMAIL PROTECTED] This is a valid bug, however a fix would be a BC break that would result in a beahviour change that was in place since 3.0 days. [2003-02-14 17:14:59] bulletbait at yahoo dot com I just stumbled across this bug recently with an older version (4.1.1) of PHP on Win32 -- verified that it still exists in 4.3.0. This one had me going in circles trying to debug. Work-arounds: $score[$num] -= 1; or $score[$num] = $score[$num] - 1; [2002-11-21 12:42:11] prgallier at yahoo dot com The following: $score[$num]--; does not affect $score[$num] if $score[$num] is uninitiated. Using $score[$num]++ does work, however. This is inconsistent. -- Edit this bug report at http://bugs.php.net/?id=20548&edit=1
#20548 [Com]: Decrement ("$x[$y]--") doesn't work on uninitiated variable
ID: 20548 Comment by: lew at mailduct dot com Reported By: prgallier at yahoo dot com Status: Wont fix Bug Type: Scripting Engine problem Operating System: Linux 2.4 PHP Version: 4.3.2-dev New Comment: This is a GROSS inconsistency in how the increment/decrement operators work, and one that coders are likely to stumble upon the hard way. Please study the effect of fixing this, at the expense of breaking a long-time quirk in BC. Breaking a quirk, and documenting it on the BC page, is better than maintaining a GROSS inconsistency in one of the basic language construct operators! Please fix this! Previous Comments: [2003-08-03 12:57:49] [EMAIL PROTECTED] This is a valid bug, however a fix would be a BC break that would result in a beahviour change that was in place since 3.0 days. [2003-02-14 17:14:59] bulletbait at yahoo dot com I just stumbled across this bug recently with an older version (4.1.1) of PHP on Win32 -- verified that it still exists in 4.3.0. This one had me going in circles trying to debug. Work-arounds: $score[$num] -= 1; or $score[$num] = $score[$num] - 1; [2002-11-21 12:42:11] prgallier at yahoo dot com The following: $score[$num]--; does not affect $score[$num] if $score[$num] is uninitiated. Using $score[$num]++ does work, however. This is inconsistent. -- Edit this bug report at http://bugs.php.net/?id=20548&edit=1
#25674 [NEW]: increment/decrement inconsistency and error
From: lew at mailduct dot com Operating system: FreeBSD 4.8-REL PHP version: 4.3.3 PHP Bug Type: Math related Bug description: increment/decrement inconsistency and error Description: There is a gross inconsistency between how the increment and decrement operators function. If you increment an empty variable, the operations works correctly. However, if you *decrement* an empty variable, the operation leaves it unchanged! See for yourself, with my clear example... Reproduce code: --- Expected result: # # Expected: #pos = 3ppp = 3 #neg = -3 nnn = -3 Actual result: -- # # Actual: #pos = 3ppp = 3 #neg = nnn = -3 (note that $neg-- fails!) -- Edit bug report at http://bugs.php.net/?id=25674&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25674&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25674&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25674&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25674&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25674&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25674&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25674&r=support Expected behavior: http://bugs.php.net/fix.php?id=25674&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25674&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25674&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25674&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25674&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25674&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25674&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25674&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25674&r=float
#25649 [Bgs->Opn]: feof behavior changed - inconsistent!
ID: 25649 User updated by: lew at mailduct dot com Reported By: lew at mailduct dot com -Status: Bogus +Status: Open Bug Type: Filesystem function related Operating System: * PHP Version: 4.3.3 New Comment: Make that, "wasteful loop". Previous Comments: [2003-09-26 11:01:33] lew at mailduct dot com As I pointed out, this used to work on an older 4.X series of PHP. My use of feof is consistent with what the PHP4 documentation states. Therefore, please elaborate if you believe it is not a bug. Without continuously doing a "stat" and bytecount of the file (aka: wasteful look), how else would you implement this? The behavior of "end of file" detection has been changed, thus creating this problem. [2003-09-26 06:30:25] [EMAIL PROTECTED] Actually this is not really bug. The way you try to implement 'tail -f' is inherently wrong. -------- [2003-09-24 20:17:03] lew at mailduct dot com My typo. Make that: $fh = fopen( '/var/log/maillog','r' ); ---------------- [2003-09-24 20:12:15] lew at mailduct dot com Description: The behavior of "feof" has changed with the newer versions of PHP (4.1.1 exhibited different behavior). I believe 4.3.X has a problem with how it handles "feof" under FreeBSD. For example, suppose I want to "tail" a logfile that keeps growing, such as "maillog" or even "httpd-access.log". In the old PHP, once I reached the end of file, "feof" would become true. If a process *added* to the file, then "feof" would become false until I read to the end of the file again. This is consistent with "tail" behavior. Under the new PHP (4.3.X), once "feof" becomes true, it *never* goes false again. Thus, it is *impossible* to "tail" a file!! Reproduce code: --- Expected result: I expect to see all the lines contained in maillog until we hit the EOF. Then I expect to see the "EOF detected" until more lines are added to maillog via another process. At that point, I expect to see the new lines of data until we hit the new EOF point again. If I replace "fopen" with "popen" like this: $fh = popen( 'tail -f /var/log/maillog','r' ); then it works. But I shouldn't have to spawn off a tail to do what the older 4.1.X version of PHP used to do. Someone has changed something in how EOF is detected (and reset). Can you please see if you can find the cause of this. Thank you for listening. Actual result: -- test line 1 test line 2 test line 3 EOF detected... sleeping EOF detected... sleeping EOF detected... sleeping ... forever ... EOF detected... sleeping (even though maillog continues to have more lines appended to it, either through a daemon or a simple "cat more.txt >> /var/log/maillog" ). -- Edit this bug report at http://bugs.php.net/?id=25649&edit=1
#25649 [Bgs]: feof behavior changed - inconsistent!
ID: 25649 User updated by: lew at mailduct dot com Reported By: lew at mailduct dot com Status: Bogus Bug Type: Filesystem function related Operating System: * PHP Version: 4.3.3 New Comment: As I pointed out, this used to work on an older 4.X series of PHP. My use of feof is consistent with what the PHP4 documentation states. Therefore, please elaborate if you believe it is not a bug. Without continuously doing a "stat" and bytecount of the file (aka: wasteful look), how else would you implement this? The behavior of "end of file" detection has been changed, thus creating this problem. Previous Comments: [2003-09-26 06:30:25] [EMAIL PROTECTED] Actually this is not really bug. The way you try to implement 'tail -f' is inherently wrong. -------- [2003-09-24 20:17:03] lew at mailduct dot com My typo. Make that: $fh = fopen( '/var/log/maillog','r' ); -------------------- [2003-09-24 20:12:15] lew at mailduct dot com Description: The behavior of "feof" has changed with the newer versions of PHP (4.1.1 exhibited different behavior). I believe 4.3.X has a problem with how it handles "feof" under FreeBSD. For example, suppose I want to "tail" a logfile that keeps growing, such as "maillog" or even "httpd-access.log". In the old PHP, once I reached the end of file, "feof" would become true. If a process *added* to the file, then "feof" would become false until I read to the end of the file again. This is consistent with "tail" behavior. Under the new PHP (4.3.X), once "feof" becomes true, it *never* goes false again. Thus, it is *impossible* to "tail" a file!! Reproduce code: --- Expected result: I expect to see all the lines contained in maillog until we hit the EOF. Then I expect to see the "EOF detected" until more lines are added to maillog via another process. At that point, I expect to see the new lines of data until we hit the new EOF point again. If I replace "fopen" with "popen" like this: $fh = popen( 'tail -f /var/log/maillog','r' ); then it works. But I shouldn't have to spawn off a tail to do what the older 4.1.X version of PHP used to do. Someone has changed something in how EOF is detected (and reset). Can you please see if you can find the cause of this. Thank you for listening. Actual result: -- test line 1 test line 2 test line 3 EOF detected... sleeping EOF detected... sleeping EOF detected... sleeping ... forever ... EOF detected... sleeping (even though maillog continues to have more lines appended to it, either through a daemon or a simple "cat more.txt >> /var/log/maillog" ). -- Edit this bug report at http://bugs.php.net/?id=25649&edit=1
#25649 [Fbk->Opn]: feof behavior changed - inconsistent!
ID: 25649 User updated by: lew at mailduct dot com Reported By: lew at mailduct dot com -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: FreeBSD 4.8-RELEASE PHP Version: 4.3.3 New Comment: There's a problem with the snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz sys5# gunzip php4-STABLE-latest.tar.gz gunzip: php4-STABLE-latest.tar.gz: invalid compressed data--crc error ... also tried tar's uncompress flag: sys5# tar -xvzf ../php4-STABLE-latest.tar.gz php4-STABLE-200309252130/ php4-STABLE-200309252130/acconfig.h php4-STABLE-200309252130/aclocal.m4 php4-STABLE-200309252130/configure tar: Skipping to next header tar: Archive contains obsolescent base-64 headers gzip: stdin: invalid compressed data--crc error tar: Child returned status 1 tar: Error exit delayed from previous errors To make sure, I deleted and downloaded the file again, and the crc problem remained. I do have a question, however... do you know if the latest snapshot actually addressed this issue, or is "try the latest snapshot" just a standard reponse? Thanks again. Previous Comments: [2003-09-25 06:09:56] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-09-24 20:17:03] lew at mailduct dot com My typo. Make that: $fh = fopen( '/var/log/maillog','r' ); -------- [2003-09-24 20:12:15] lew at mailduct dot com Description: The behavior of "feof" has changed with the newer versions of PHP (4.1.1 exhibited different behavior). I believe 4.3.X has a problem with how it handles "feof" under FreeBSD. For example, suppose I want to "tail" a logfile that keeps growing, such as "maillog" or even "httpd-access.log". In the old PHP, once I reached the end of file, "feof" would become true. If a process *added* to the file, then "feof" would become false until I read to the end of the file again. This is consistent with "tail" behavior. Under the new PHP (4.3.X), once "feof" becomes true, it *never* goes false again. Thus, it is *impossible* to "tail" a file!! Reproduce code: --- Expected result: I expect to see all the lines contained in maillog until we hit the EOF. Then I expect to see the "EOF detected" until more lines are added to maillog via another process. At that point, I expect to see the new lines of data until we hit the new EOF point again. If I replace "fopen" with "popen" like this: $fh = popen( 'tail -f /var/log/maillog','r' ); then it works. But I shouldn't have to spawn off a tail to do what the older 4.1.X version of PHP used to do. Someone has changed something in how EOF is detected (and reset). Can you please see if you can find the cause of this. Thank you for listening. Actual result: -- test line 1 test line 2 test line 3 EOF detected... sleeping EOF detected... sleeping EOF detected... sleeping ... forever ... EOF detected... sleeping (even though maillog continues to have more lines appended to it, either through a daemon or a simple "cat more.txt >> /var/log/maillog" ). -- Edit this bug report at http://bugs.php.net/?id=25649&edit=1
#25649 [Opn]: feof behavior changed - inconsistent!
ID: 25649 User updated by: lew at mailduct dot com Reported By: lew at mailduct dot com Status: Open Bug Type: Filesystem function related Operating System: FreeBSD 4.8-RELEASE PHP Version: 4.3.3 New Comment: My typo. Make that: $fh = fopen( '/var/log/maillog','r' ); Previous Comments: [2003-09-24 20:12:15] lew at mailduct dot com Description: The behavior of "feof" has changed with the newer versions of PHP (4.1.1 exhibited different behavior). I believe 4.3.X has a problem with how it handles "feof" under FreeBSD. For example, suppose I want to "tail" a logfile that keeps growing, such as "maillog" or even "httpd-access.log". In the old PHP, once I reached the end of file, "feof" would become true. If a process *added* to the file, then "feof" would become false until I read to the end of the file again. This is consistent with "tail" behavior. Under the new PHP (4.3.X), once "feof" becomes true, it *never* goes false again. Thus, it is *impossible* to "tail" a file!! Reproduce code: --- Expected result: I expect to see all the lines contained in maillog until we hit the EOF. Then I expect to see the "EOF detected" until more lines are added to maillog via another process. At that point, I expect to see the new lines of data until we hit the new EOF point again. If I replace "fopen" with "popen" like this: $fh = popen( 'tail -f /var/log/maillog','r' ); then it works. But I shouldn't have to spawn off a tail to do what the older 4.1.X version of PHP used to do. Someone has changed something in how EOF is detected (and reset). Can you please see if you can find the cause of this. Thank you for listening. Actual result: -- test line 1 test line 2 test line 3 EOF detected... sleeping EOF detected... sleeping EOF detected... sleeping ... forever ... EOF detected... sleeping (even though maillog continues to have more lines appended to it, either through a daemon or a simple "cat more.txt >> /var/log/maillog" ). -- Edit this bug report at http://bugs.php.net/?id=25649&edit=1
#25649 [NEW]: feof behavior changed - inconsistent!
From: lew at mailduct dot com Operating system: FreeBSD 4.8-RELEASE PHP version: 4.3.3 PHP Bug Type: Filesystem function related Bug description: feof behavior changed - inconsistent! Description: The behavior of "feof" has changed with the newer versions of PHP (4.1.1 exhibited different behavior). I believe 4.3.X has a problem with how it handles "feof" under FreeBSD. For example, suppose I want to "tail" a logfile that keeps growing, such as "maillog" or even "httpd-access.log". In the old PHP, once I reached the end of file, "feof" would become true. If a process *added* to the file, then "feof" would become false until I read to the end of the file again. This is consistent with "tail" behavior. Under the new PHP (4.3.X), once "feof" becomes true, it *never* goes false again. Thus, it is *impossible* to "tail" a file!! Reproduce code: --- Expected result: I expect to see all the lines contained in maillog until we hit the EOF. Then I expect to see the "EOF detected" until more lines are added to maillog via another process. At that point, I expect to see the new lines of data until we hit the new EOF point again. If I replace "fopen" with "popen" like this: $fh = popen( 'tail -f /var/log/maillog','r' ); then it works. But I shouldn't have to spawn off a tail to do what the older 4.1.X version of PHP used to do. Someone has changed something in how EOF is detected (and reset). Can you please see if you can find the cause of this. Thank you for listening. Actual result: -- test line 1 test line 2 test line 3 EOF detected... sleeping EOF detected... sleeping EOF detected... sleeping ... forever ... EOF detected... sleeping (even though maillog continues to have more lines appended to it, either through a daemon or a simple "cat more.txt >> /var/log/maillog" ). -- Edit bug report at http://bugs.php.net/?id=25649&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25649&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25649&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25649&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25649&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25649&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25649&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25649&r=support Expected behavior: http://bugs.php.net/fix.php?id=25649&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25649&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25649&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25649&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25649&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25649&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25649&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25649&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25649&r=float
