Note: Calling sleep(5) before dumping the PDF solves the problem, so I think the bug is related to a memory management/multithreading problem...

did you checked if php_stream_read() was returning the right filesize value? that was the first bug.

Can you reduce this to the simplest combination of scripts?
(That don't use sessions).

@wez: These scripts don't use sessions. They run of a CD in a single-user-environment.

@nicos: Calling the "passthrough"-script directly works without errors. But calling it in an frameset (together with two other scripts) crashes when outputting a file > 100k,

The php_stream_read() returns the correct filesize.
The fact, that the parrallel execution of three scripts of one handles a big file may be the source of the problem.

There are no write-accesses. Only Read-Accesses to small config-files.

Removing the "big-files-passthrough" let the scripts run properly.

The following snippets illustrate the environment


[frameset.php]
->frame1.php
->frame2.php
->frame3.php


[frame1.php]
<?
header("Content-type: application/pdf\n");
readfile("some_100k_large.pdf");
?>

[frame2.php]
<?
echo "Something";
?>

[frame3.php]
<?
echo "else";
?>

That last comment should let us open it back.

Removing the "big-files-passthrough" let the scripts run properly.

@Wez: can you check it? may be its because of the position of the stream at the end of the execution of the first checksize?

In addition

[frame1.php]
<?
// Adding sleep(5) will solve the problem the first time a
// >100k File is called. The next output of a >100k File
// will crash again...
sleep(5); 
header("Content-type: application/pdf\n");
readfile("some_100k_large.pdf");
?>

May be its because that the stream hasn't enough time to get its new position. I didn't read streams.c/h well enough too.

Did this work in any previous versions of PHP?
Is it stricly win32 thing? Does this workin in e.g. Linux?

I just fixed (I hope) a socket-shutdown bug (#16114).
The interesting thing is that this is only to do with
writes to sockets opened by streams (so it should not
affect PHP output).

It might be that the Microweb server also has a similar
bug, or that it has some other threading issue.

It doesn't make sense for this to be related solely to
streams, as they aren't time-dependent, and they are
certainly not dependent on other PHP processes.

Can you try reproducing the problem using Apache, PWS
or IIS?
Can anyone reproduce this on another platform?

I have a simmilar problem on windows 2000 Server with IIS4.
I use this script (just a part):
header("Content-type: Download");
header("Content-Disposition: attachment; filename=".$Data->SWFileName);
$fp = fopen ($GLOBALS['FileLocation'].$Data->SWFileName, "rb");
fpassthru($fp);

The problem is that on our development machine (Linux) everything works like a charm, but on our "Production" server with Win2k Server & IIS not.
There is a small JavaScript which calls the file sending script usimg window.location='getfile.php?fileid=56'

The problem place is that the time between request and displaying the "save" dialog is very large. (1-2 minutes or so) I can't get it to execute faster.
I will try to use the fread().

Later

SelfMan

As a sanity check, you're not using output buffering or ob_gzhandler, or zlib.output_compression or transparent
SID/session rewriting, are you?

For me, I dont have output buffering or ob_gzhandler,
or zlib.output_compression or transparent SID/session rewriting enabled. I tested even a max execution time of a day.

and did you try the most recent snapshot as I suggested
on the 13 Oct?
And could you reproduce the issue using a different web server?

None of them has been used (output buffering or ob_gzhandler, or zlib.output_compression or transparent SID/session rewriting). The fopen() -> $val = fread()-> echo $val worked fine. The response was much quicker.
Never minad... I have solved the problem otherwise. And the data have moved to a differen server with higher capacity.

Regards SelfMan

I'm experiencing something similar on Linux Apache using Version 4.1.2.  As far as I know it worked before I upgraded from an earlier version. 

My code looks like this:

$file="/path/to/file"; 
$fp  = fopen($file, "r");

$size=filesize($file);

$contents = fread($fp, $size);
fclose($fp);

Header("Content-Type: $type");
Header("Content-Disposition: attachment; filename=$downloadname");
header("Content-Length: $size");
header("Content-Transfer-Encoding: binary");
echo $contents;


filesize() is reporting the size properly.  The code works perfectly for smaller files, but the fread() fails for files larger than 19 MB or so and I got a page cannot be displayed error.  All the files being downloaded are PDF files.

The problem can be reproduced using Apache/Win32 using the script posted at 13 Oct 10:19am.

I tried the newest snapshot (31-Oct-2002 03:28). Furthermore, the previous snaps and different release versions (>4.2.2) don't work. I deleted versions < 4.2.1, so I can't test them any more.

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

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.

No feedback was provided for this bug for over 2 weeks, 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".