From: phofstetter at sensational dot ch
Operating system: Linux and Mac OSX
PHP version: 5.2.3
PHP Bug Type: Streams related
Bug description: bzip2.compress loses data in internal buffer
Description:
------------
When bzip2.compress is attached to a stream and enough data is created so
the output will be larger than some internal buffer, all data in the last
not totally full buffer seems to get lost on the way out.
The sample code contains quite a lot of filler text which is needed to
actually fill up the internal buffer full enough to trigger the problem.
I always had this problem since the stream filters got introduced into
PHP, but now I could finally create a very much reduced test case
explaining the problem.
Reproduce code:
---------------
<?
$str = "BEGIN (%d)\n
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
commodo consequat. Duis aute irure dolor in reprehenderit in voluptate
velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat
cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id
est laborum.
\nEND (%d)\n";
$h = fopen($_SERVER['argv'][1], 'w');
$f = stream_filter_append($h, "bzip2.compress", STREAM_FILTER_WRITE);
for($x=0; $x < 10000; $x++){
fprintf($h, $str, $x, $x);
}
fclose($h);
echo "Written\n";
?>
Expected result:
----------------
If I call the script with
./script.php blah
and then use
bzcat blah
I expect the complete data output to the console.
from
BEGIN (0)
to
END (9999)
Actual result:
--------------
bzcat outputs until somewhere around "END (9207)" and then bails out with
bzcat: Compressed file ends unexpectedly;
perhaps it is corrupted? *Possible* reason follows.
bzcat: Unknown error: 0
Input file = blah, output file = (stdout)
It is possible that the compressed file(s) have become corrupted.
You can use the -tvv option to test integrity of such files.
You can use the `bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.
and true enough - the file is not completely written.
--
Edit bug report at http://bugs.php.net/?id=42117&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42117&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42117&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42117&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42117&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42117&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42117&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=42117&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=42117&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42117&r=support
Expected behavior: http://bugs.php.net/fix.php?id=42117&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42117&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42117&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42117&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42117&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42117&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=42117&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42117&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42117&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42117&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=42117&r=mysqlcfg
