php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #18221 Massive slowdown in fwrite() when not printing any text
Submitted: 2002-07-08 06:07 UTC Modified: 2002-07-11 01:47 UTC
From: rca at spin dot ch Assigned:
Status: Not a bug Package: Filesystem function related
PHP Version: 4.2.1 OS: Linux 2.2.16
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: rca at spin dot ch
New email:
PHP Version: OS:

 

 [2002-07-08 06:07 UTC] rca at spin dot ch 
Try the following code snippet on its own page:


$filename = "foo.txt";
$content = "blah";

$fd = fopen($filename, "a");
fwrite($fd, $content);
fwrite($fd, "\n");
fclose($fd);


You'll notice that the file is created just as intended, but the browser will be left waiting for data for a LONG time. However, if you add this to the end of the script:

print "test";

The page is finished and sent to the browser immediately, no delays at all.

This was found by one of our students, not by me :)

Verified on PHP 4.1.2 using Apache 1.3.12 and 1.3.20, the former on kernel 2.2.16, the latter 2.4.2.

PHP configure line:  './configure' '--with-png-dir=/usr' '--with-mysql=/usr/local/mysql' '--with-apxs' '--with-swf=/usr/lib/ swf' '--with-config-file-path=/etc/httpd/php.ini' '--enable-ftp' '--with-gd=/usr/' '--with-jpeg-dir=/usr' '-- with-ttf' '--with-zlib' '--with-t1lib' '--with-ming' '--with-config-file-path=/etc/httpd/php.ini' '--enable- trans-sid' '--with-imap' '--with-imap-ssl=/usr/include/openssl'

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-07-08 06:08 UTC] derick@php.net 
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.
 [2002-07-09 04:46 UTC] rca at spin dot ch 
Also tested this in 4.2.1 on the same Apache/Linux combination. It's still a bug.
 [2002-07-09 08:09 UTC] sniper@php.net 
I can not reproduce this with latest CVS checkout of PHP (php 4.3.0-dev) so please try this snapshot: 

http://snaps.php.net/php4-latest.tar.gz

And with what browser did this happen with? I get immediate
'Document contained no data' error with Netscape..

You should also update Apache to 1.3.26..as those versions you have are too old.
 [2002-07-10 02:17 UTC] rca at spin dot ch 
Hmm, now that certainly sheds a new light on all this. With MSIE 5.0/win32 I can't reproduce the bug either, but any version of Opera for win32 or Linux will hang. I couldn't try Mozilla yet, but I'm guessing that I'll also get a "Document contained no data" error.

So is this the browsers' fault for not agreeing on a standard way to deal with blank pages or PHP's fault for producing them? 

I've had include()'d files (which don't produce output except for blank lines) work just fine, showing a blank across all browsers. Just when these filesystem functions are used there's unpredictable behavior.
 [2002-07-11 01:47 UTC] sniper@php.net 
It's just Opera specific, and especially Opera 6.x specific
since I couldn't reproduce it with 5.05. And it doesn't really slowdown or anything. It just doesn't update the 
mouse pointer. :)
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 19 00:01:29 2024 UTC