#2549 Strange happenings with bzip2.compress filter
Submitted: 2004-10-17 16:26 UTC
From: pilif at pilif dot ch Assigned:
Status: Open Package:
PHP Version: 5.0.2 OS: Linux 2.6
Roadmaps: (Not assigned)    
Subscription  


 [2004-10-17 16:26 UTC] pilif at pilif dot ch
Description: ------------ OK. First off, I really, really tried to produce a reproducible, small testcase, which I failed to do. The testcase is somewaht larger than thos 20 lines and it - unfortunately - requires an MS-SQL-Server to reproduce. OK. What I did was $fp = fopen('php://output', 'w'); $param = array('blocks' => 1, 'work' => 0); stream_filter_append($fp, 'bzip2.compress', STREAM_FILTER_WRITE, $param); To bz-compress all output sent to this file-handle which is then sent to my Client (which understands the bzip-Format, of course). With all simple cases I did, this worked, but as soon as MS-SQL-Server comes into play, this is what happens: % php bugtest.php | bzcat -tvv (stdin): [1: huff+mtf rt+rld] [2: huff+mtf rt+rld] [3: huff+mtf rt+rld] [4: huff+mtf rt+rld] [5: huff+mtf rt+rld] [6: huff+mtf rt+rld] [7: huff+mtf rt+rld] [8: huff+mtf rt+rld] [9: huff+mtf rt+rld] [10: huff+mtf rt+rld] [11: huff+mtf rt+rld] [12: huff+mtf file ends unexpectedly I think, this thing must be related to memory-corruption, as moving around those fwrite-lines a bit, gets it to work here and then. Also outputting a bzip-buffer full of static data cures the problem. I'm terribly sorry that I cannot be more specific. I just used two full days to get where I am now, but I will certainly not stop and continue investigating. You can use the `bzip2recover' program to attempt to recover data from undamaged sections of corrupted files. -> As you can see, the bzip-file somehow gets corrupted. A bit research turned out that it is incomplete - the last part of the buffer is never flushed to the output stream. I'm connecting to the server via FreeTDS from my Linux machine. I'm not really sure whether this problem really is in bzip2.compress. It may well be in the mssql-extension or even in freetds, but I'm reporting this here as I have no problems whatsoever when letting it run uncompressed. As I said: With any simpler case, it just works as expected. Reproduce code: --------------- http://www.pilif.ch/bugtest.phps (commenting out one fwrite()-Line or another will stop the bug. This is the combination where I can reproduce it every time. Ask me, if you need a Dump of the database.) Expected result: ---------------- % php comptest.php | bzcat -tvv (stdin): [1: huff+mtf rt+rld] [2: huff+mtf rt+rld] [3: huff+mtf rt+rld] [4: huff+mtf rt+rld] [5: huff+mtf rt+rld] [6: huff+mtf rt+rld] [7: huff+mtf rt+rld] [8: huff+mtf rt+rld] [9: huff+mtf rt+rld] [10: huff+mtf rt+rld] [11: huff+mtf rt+rld] [12: huff+mtf rt+rld] [13: huff+mtf rt+rld] ok Actual result: -------------- % php bugtest.php | bzcat -tvv (stdin): [1: huff+mtf rt+rld] [2: huff+mtf rt+rld] [3: huff+mtf rt+rld] [4: huff+mtf rt+rld] [5: huff+mtf rt+rld] [6: huff+mtf rt+rld] [7: huff+mtf rt+rld] [8: huff+mtf rt+rld] [9: huff+mtf rt+rld] [10: huff+mtf rt+rld] [11: huff+mtf rt+rld] [12: huff+mtf file ends unexpectedly

Comments

 [2004-10-17 16:50 UTC] pilif at pilif dot ch
Sorry. Corrected the category and the Version of PHP - the former I've overseen on the submission-form, the latter I could not set correctely on submitting.
 [2004-10-18 09:33 UTC] pilif at pilif dot ch
OK. Me again. I can reproduce it now also with a PostgreSQL-Packend. A bit hacking around in the script showed me something interesting: //do work sleep(2); exit; right before the sleep - the output seems to stop in the middle of whatever the script is doing. Then the script exits and bzcat -tvv reports the error. If I do this: // do stuff fwrite($fp, '<!-- '); fwrite($fp, str_repeat('+=', 5000)); fwrite($fp, '-->'); fclose($fp); sleep(2); exit; to fill the buffer a little bit more, something interesting happens: the output still stops in the middle of the XML I'm outputting (see test case), waits those two seconds and *then* outputs the rest (the rest of the XML followed by those fill-characters). When I add some Pear::Log-Statements to the testcase, I can prove that the XML-generation-part is definitely finished before I com to the junk-outputing-part. So. Forget my previous note. This bug *must* be within the output-filter. Somehow a buffer does not seem to get flushed here and then. Question: Is this maybe related to http://bugs.php.net/bug.php?id=29521 ? Philip