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

go to bug id or search bugs for

Bug #41280 Local file reading distorts echo
Submitted: 2007-05-04 10:23 UTC Modified: 2007-05-12 01:00 UTC
From: wimroffel at planet dot nl Assigned:
Status: No Feedback Package: Filesystem function related
PHP Version: 5.2.2 OS: Windows XP
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: wimroffel at planet dot nl
New email:
PHP Version: OS:

 

 [2007-05-04 10:23 UTC] wimroffel at planet dot nl 
Description:
------------
While reading a local file Windows (both XP and ME) many empty reads are generated (reading from internet works much better). So you need a "while !feof" loop and cannot trust on a test on the size of $data.

The killer in the attached code is the "echo $data". The problem does not happen if you collect the whole file in a variable and echo it at once. So it seems some problem with echo - probably with the data produced by an empty read.

Sometimes the crash happens after only a few freads. Other times it can take a few dozen.

The echo problem happens only under Windows XP and not under Windows ME. I am using Apache 2.2.

Reproduce code:
---------------
/* myfile.txt is a large (about 100k) local file */
  $fpi = fopen("myfile.txt", "rb"); 
  while(!feof($fpi)) /* block read the rest */
  { $data = fread($fpi,4096);
    echo $data;
  }
  fclose($fpi);


Expected result:
----------------
a reproduction of the file on screen.

Actual result:
--------------
The screen flickers a few times while a partial result is produced. Then you get a "Cannot find server" message. 

Some times the first display goes right, but the problem happens after a refresh.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-05-04 10:31 UTC] tony2001@php.net 
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
 [2007-05-04 13:09 UTC] wimroffel at planet dot nl 
I am not familiar with those debugging procedures. I tried, but I see no result.

I installed MSVC6 (still had it lying somewhere from MSDN). I downloaded the debug-pack and unpacked it. I copied the files (they are all .pdb files) to both the php and php/extensions directory. 

And then it stopped for me. I am unaware when PHP crashes and I never see a cancel button that I could press.

What I did find find in other experiments was that even when all output is echoed at once the data is sometimes read incorrectly. It looks like there is some memory leak.

I tested it on two XP computers with very different setups and hardware.
 [2007-05-04 13:19 UTC] tony2001@php.net 
>And then it stopped for me. I am unaware when PHP crashes and 
>I never see a cancel button that I could press.

Well, then there are no crashes and you are wrong.

>What I did find find in other experiments was that even when all
>output is echoed at once the data is sometimes read incorrectly. 

"Incorrectly"? How did you compare the data? Looking on the screen?

>It looks like there is some memory leak.

What are you talking about?
 [2007-05-04 18:59 UTC] wimroffel at planet dot nl 
> Well, then there are no crashes and you are wrong.

I don't know what a crash looks like and whether what I see is a crash. I don't know whether I installed MSVC correctly. But I do know that the software is behaving in a wrong way.

>>What I did find find in other experiments was that even when all
>>output is echoed at once the data is sometimes read incorrectly. 

>"Incorrectly"? How did you compare the data? Looking on the screen?

Yes. The data is echoed to the screen. And as it is text with some html changes are often immediately visible.

>>It looks like there is some memory leak.

>What are you talking about?

When the data that is echoed on the screen is incorrect usually one or a few bytes are incorrect. However, once I saw a part of a variable list like you see sometimes when you look at an exe file in a text editor.

I have spent years developping software myself - in Borland C. That is years ago. But I know what I am talking about.

I developped a PHP/MySql application under Windows ME. Now I am trying to port it to XP, but this bug is making it impossible. The bug is still there when I remove the MySql part. And it is no longer there when I save the page as HTML. So I have to conclude that it is PHP.
 [2007-05-04 19:56 UTC] tony2001@php.net 
>Yes. The data is echoed to the screen. And as it is text with 
>some html changes are often immediately visible.

What kind of changes? Where can I see them?

>>It looks like there is some memory leak.
>When the data that is echoed on the screen is incorrect usually one 
>or a few bytes are incorrect. However, once I saw a part of a
>variable list like you see sometimes when you look at an exe file 
>in a text editor.

Well, I'm afraid it has nothing to do with memory leaks.
 [2007-05-07 02:01 UTC] dayseye at 21cn dot com 
I guess it's a internal charset problem. does Borland C handle ANSI/UTF-8 in the same way both in WinME and WinXP? If not, you must check the text file what charset it's using.
 [2007-05-12 01:00 UTC] 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".
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Oct 24 00:00:02 2025 UTC