#20535 [Fbk]: zLib crashes when trying to gzuncompress
ID: 20535
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Zlib Related
Operating System: RedHat 7.2
PHP Version: 4.2.3
New Comment:
Are you sure your base64-encoded data decodes to a valid zlib
compressed string?
If I use the file from the URL you posted, zlib wants to have a lot of
memory (> 400 MB, then I stopped testing) to decompress it, so maybe
the data is corrupted or the uncompressed data is too big.
Previous Comments:
[2002-11-23 13:18:02] [EMAIL PROTECTED]
OK, that report did not do well. Here you can find the text of the test
case:
http://www.network54.com/zlibcrash.txt
[2002-11-23 13:15:17] [EMAIL PROTECTED]
This bug doesn't do anything with files. Note that if I add a length
argument to gzcompress() it does not crash.
Test case:
$zlibcrash=base64_decode("
eNrs22OQZl23Lui0bdu2zUrbfNK2bdtWJaqST6LStm07s9KqNPp7P+zYJ86O2Ke7Dzv635xzjTFm
rBWxfl1xA/hYOfh8rflY+AF8PHy+rnzcfGR2jpbWDtZmZPyufJx8ZBy87Nxsf63Z+Misnf5a/K2D
jI2Vi4mNg52JlZuLiZ3jr1MuPjKAqZu1o8Nfm79VSJpZu/29mvVfD4zMAG7mZPzWfKws7NzcPGzs
LOz/7HN3s3J0+auYl49MAuBhTqJm5Wj+z/vN7QHWdn8fxMNH5vq3cxETazdXNxdzgD2Tg7nbP6vc
rN3s/t7B8bd53xzdSFQdzUjc3B3M+UjUrcxJxOwcHczMSawdSNz+tuNg4SKhATiYkdg7upjT/tX1
t7e2N3d1BVj+fQY3KwsLH5nXeo2+rSs+d8ZHdw/YATJ5h1RaKk/2ZKkFFaVOAM2Blk6Bl2VPa69D
Ujywow+sXdI94KPAlbldRvbBx+Z3jKkcxSzI1f0m9Ou4ROZy7SmWvwFyuaMctprlxrxb+uXkxGz2
E2jPQ41cOcKljGVGLXu6kabF1fl6i1zjrYF5ThIfun3w74gFg46HGvb77RW/w2zWOnv+LCDLlDEc
/hSZz0rGmJ3dRjaXGybxEiRDCfLD1s85/2ezmwqY4mG1WuBe/y9Cro7hlFqO5cXucxtLvw4Yqia+
7/C2RlmRBT3tAiP6rybmTIzDHhpuzX5uMYge2nAdvYr6BqYv8Yo6G2XstMZ94UaPc9lVqWgzsM7W
el8dqV2AOqxCZ3LZlIAa/NnfloEdXl+JXyk9hu176jJ4BgfeV8N7HCvFzqBmNkD+RGJZcvxhlq2i
z/ddcKJnpXnow4OBurdWloltTy4hFmTxRdQZxu5Ygvv5tdy+To/8mikEam3eFi54uy33fKfqO0nz
VqcjxZTf6MJ2A8MZHt8Sw3C4hHcY6hORKAx575vOYpd+tsFUHGPveB3NuGq96d3Pug+RA2YaPGmT
S+MNRC3QFK1SbFMXGmHgewubkOhXXBqzJcdMdvNiNaDOe8KcJAJ9xwtvL4+WynRe8bnvcs4T+avr
ja1oTXp4nnwLFetjx7d54KoGhKHACGlpkzrlNR3ezyASGzkDiRGWdY1hCuqP1pZkTOmiUI/Q9LSV
C7hzp9bcezxuvaOOcGngfmZT7/COusVqbKiGwb81FTV7f1xFW4tsgzXWKxg0uk7xSeALmvG4k/I1
rEkmQ+9gJXGk+qjIuh7sG2M5gKcH2WGlg9+CUTT3Mcw3QhY+u7tIFimbv2h70bB+W6r9Bq+h50mv
pD/CUmeQWhRYvLcboa93ihQ39HUAIy/YV6LT2Vf2EmRKNRoQnf9wSUcrbW7r0eWBwnXKvIJtCoz6
QCOmxHaGY7ijcmO6TijdVVWwEo3qxgowviaRNOKp1IFzV4pXhhxiSImBLwPBDxcUS4FuRCgW4DTp
7Sz7WFc3fmpvDp3liCDis+6TGDeOBIfKAxfW1pnK8VSqrzvpynPRdybQhrJrcG0SAXXJLivac/xl
xLOFU6bHiC3hkyAo+hXGuFb0MwbGOpPUNtTvdiEhS6VBFkjAx/hdHBvgomHX2vwdCWPOs1sZzVFM
P5qT5M1aTtLIuk/0UjEMZDgF7laUQsXzSB4enfKRP78yLqJ70uhncGLfsLAIgdUY/7tiLleB1ZWV
nrqWbaFZNjSKX5Qq/HlOSvgPE1cU4h/QXnsOBnOhR8CZYK6RtvQNvgiQ4h+9r9CrR7xCRGKOmiyi
dGoNWRWuOGZ9MeW4wxp/zOT4rfY0d5dnXcb5OW5LUwXFcIDfyTjiY9NQCKoegGuEDwVi3D/Ipoxr
jaFI8fy3YFdkoWHlOGI3icIC1l4hR5GJwZYwWVWUMrpWfzJcxRLZGLlOkLbNAbtCCDlWDNyM43Gu
hHMmrDKPCTThc1VpK7gYbByqGfxFTcPjQ8/2kzJVwgrY1kfI8OdD7MoKQ0WjVkkZQqMQFNf4tFLe
tATSIaWNGfjxlNJ//ubFR5Vn7V7F9uMeXHY9kHnnSv9MS5lUAEgXbxW/R15k1Et72uZyThpyCdHX
jXd+yd9lUrG1m1Ol4JUWTu4UFc0xfn4WnbX/UUokXhikylmV5KpPZIWejBs4IBqmEPy8YlYqEPh8
HCEOHMRmpEmdzvmTCl3+fejy8/One26g8tXOwYRC7ufj6qfpSnkoQnGNNb+xlgACOKyBcpBo5aK2
Sgke/wYb7ie5houATbTNJwy8bB+kCdnQkjkZSs1uqEc2xJQIRp4CuKJjrOwmhXVyjfbCAC6zLz6p
oSLNkEKzkwFqiON3PHpIpe99Eb3BGMVlS6EPHBJ0+Sce37x1tPQfzwusHKxrhwTmOzubXaU3M4ZO
4d5RIYdMbkjHLGNnnepeYGy+RaDXr879TpWT+9JQfwahQJWG1Nrj+6Z7CnkN6HL/MTDfUZoQLFu8
AaVRCbJHQIkFcSX19KzHPGwO2hUiLsTve/84QHw1mv/K7RJqawIepEQXQ6aDQrCKuGPhKJEhRkPF
0uFmjyH1k48GR1bQLM9lz5g+A26w++O8sKfwvRTvFIJARvqDqT07ydUhdmmyOW2gn1YRkpElUOhi
FZoE/dUmLrBO9Y8hwtxbt84TbGH4MY0gDV3eXHKkdUTNdN8M2kjd5tPO+wvQRWBrOujlgBo7jwOX
UX5TKy/ZS7ZxPjOEdj1acW1NH6RnroPbGIQ1S8YeWTMjRLd5FoLBaS6BjiuycfM+0MIlqNKOC5zg
OTTXOvbB9vhwxDGFT+cVSe6C2H2Vdllpwxg0qznFWPSW4ag4tHoAy4w223LJD/Yqem0TicAzrT8s
Xy5zN/nEgZ9lkdL/VsUvLxICHkLaZIPDFkrxW23TpT+RoTGFuk5kSKgyF5mq69TeW15HUFhCr/xP
ZvVJLDxlIbljSkmMOMzeUmgsRHR2gG3rfhN65w8FMGY4mA5o4zCM9xvsQYL6UwDc9lprpb0cA/0P
TrkgCQ8TavyVSVq/NcPu9u7PgyPefHuVXQJerENu4B4TnSHpIsCObZ1WwM36jW1AyGU8Jo6iMSIQ
/A3yJ1+Hps6YC3vvtzjnHVgVvb6Pat/gHu9YvD7QBYalkgElgiHtjfXxl+HP7S+H+pESZgbgNRr/
5u6P8ETJyyt270R29l4K7yhe6TjTYLKCBCXQlRece/UCcjWh3qMWXxxTI5rtjtrES6Tsvl+jKN5a
XAHrNuL8OnM18ihElJQaTTe3MqKcom1WA087H1ZCD/bnNiZUN4+MCqUGuv0xltxex65SN6hN1zS6
wNx7gvuOEpshVgpf14FRHW5Y6stnBB1q+N8rajy3rQalIwxFh1XMtlv4t3PEPJD4PuMyKS7A47EL
cgxIqt/WvYpEl+hG04oXZsdCIy6UuzryvOXoyDRArUTt41niu8JBMVBnBpb7zHtkR2uBoX1FP3lM
gtpeV3jvKI85f41cM0cwMdSWcg/2wcSvbOfxhckO623QnFU8lggL37mWyiilKp7SHDYwvgfJzO5t
nePmsIivZ3vc8bJUaJKz5zsAE4qAWM2udzdnZp4NBbHT3iZhaZsyTyOMcbQXEcCDORobsDT2vLgw
hrZmaNY7tvOdOhaNoXA+AFSFhZSUdCAr1fjKesU8BxE2Xkbx4MpWbznFj2w1chH0us+mFdAUeWAW
LFkBRoHrwB6juRbW1jX3joHB9vYVgBBFWat2Evh162m6fhtGIoFYJ4G46svjp9V30o/teSdf9y0E
tO4Z2f2XcdM7hIgBWYjCmoUjiNkWmBH7vImmfIl91lVpFHGHT5paTAwRR43z1vqfC3t61sbgV/HI
oekgTneotyusPfw8CYShcdn11AZjaQH91V/5tiBNo7wq9JYAeWwxAvRsf
#20551 [Fbk]: Output compression causes segfaults (ob_gzhandler)
ID: 20551
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Output Control
Operating System: RedHat 7.2
PHP Version: 4.2.3
New Comment:
In 4.3 zlib.output_compression will be PHP_INI_ALL and you can change
the value if the headers are not sent.
Also images won't be compressed automatically.
Previous Comments:
[2002-11-27 14:02:12] [EMAIL PROTECTED]
zlib.output_compression is PHP_INI_SYSTEM|PHP_INI_PERDIR so it can't be
set in a script according to the manual (ini_set). Is this correct?
Does this change in 4.3?
[2002-11-27 13:55:13] [EMAIL PROTECTED]
Using
ini_set ( "zlib.output_compression", 1);// or "On" or 4096 ...
instead of:
ob_start ('ob_gzhandler');
does not actually compress pages...
[2002-11-27 13:12:35] [EMAIL PROTECTED]
The problem with setting it system wide is that it will try to compress
images and javascripts. No browser likes compressed images and Netscape
dies on compressed javascripts.
Or are you suggesting that I use:
ini_set ( "zlib.output_compression", 1);
instead of:
ob_start ('ob_gzhandler');
??
Does this work in PHP 4.2.3?
[2002-11-27 11:30:07] [EMAIL PROTECTED]
We recommend using zlib.outputcompression instead of ob_gzhandler;
maybe this will solve your issues, without
the need to upgrade PHP.
[2002-11-27 09:31:15] [EMAIL PROTECTED]
One thing I forgot to add: I tried backporting all the fixes from CVS
that referenced crashes/segfaults from zlib.c, output.c, and streams.c
with no improvement.
In the middle of the night, I'm going to temporarily install 4.3RC1
which will disable the accelerator and kick the load average to the
roof, but hopefully I'll be able to check the error log for segfaults.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/20551
--
Edit this bug report at http://bugs.php.net/?id=20551&edit=1
#20535 [Csd]: zLib crashes when trying to gzuncompress
ID: 20535
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Zlib Related
Operating System: RedHat 7.2
PHP Version: 4.2.3
New Comment:
You can avoid the going overbord by giving an optional maximal length.
The documentation about the maximal tried length (if no length was
given) was wrong, it goes until 2^15.
Previous Comments:
[2002-11-24 12:14:11] [EMAIL PROTECTED]
You are correct. I did some checking and found that the data stream was
truncated to 65K, and therefore was invalid. It would be nice if it did
not go overboard like this, but I'm chaulking this up to user error.
Ick, that's me.
BTW - the loop that goes and gets a bigger buffer has docs that say it
goes to len()*2^8. But maxfactor is 16 and the check is for 400 MB, then I stopped testing) to decompress it, so maybe
the data is corrupted or the uncompressed data is too big.
[2002-11-23 13:18:02] [EMAIL PROTECTED]
OK, that report did not do well. Here you can find the text of the test
case:
http://www.network54.com/zlibcrash.txt
[2002-11-23 13:15:17] [EMAIL PROTECTED]
This bug doesn't do anything with files. Note that if I add a length
argument to gzcompress() it does not crash.
Test case:
$zlibcrash=base64_decode("
eNrs22OQZl23Lui0bdu2zUrbfNK2bdtWJaqST6LStm07s9KqNPp7P+zYJ86O2Ke7Dzv635xzjTFm
rBWxfl1xA/hYOfh8rflY+AF8PHy+rnzcfGR2jpbWDtZmZPyufJx8ZBy87Nxsf63Z+Misnf5a/K2D
jI2Vi4mNg52JlZuLiZ3jr1MuPjKAqZu1o8Nfm79VSJpZu/29mvVfD4zMAG7mZPzWfKws7NzcPGzs
LOz/7HN3s3J0+auYl49MAuBhTqJm5Wj+z/vN7QHWdn8fxMNH5vq3cxETazdXNxdzgD2Tg7nbP6vc
rN3s/t7B8bd53xzdSFQdzUjc3B3M+UjUrcxJxOwcHczMSawdSNz+tuNg4SKhATiYkdg7upjT/tX1
t7e2N3d1BVj+fQY3KwsLH5nXeo2+rSs+d8ZHdw/YATJ5h1RaKk/2ZKkFFaVOAM2Blk6Bl2VPa69D
Ujywow+sXdI94KPAlbldRvbBx+Z3jKkcxSzI1f0m9Ou4ROZy7SmWvwFyuaMctprlxrxb+uXkxGz2
E2jPQ41cOcKljGVGLXu6kabF1fl6i1zjrYF5ThIfun3w74gFg46HGvb77RW/w2zWOnv+LCDLlDEc
/hSZz0rGmJ3dRjaXGybxEiRDCfLD1s85/2ezmwqY4mG1WuBe/y9Cro7hlFqO5cXucxtLvw4Yqia+
7/C2RlmRBT3tAiP6rybmTIzDHhpuzX5uMYge2nAdvYr6BqYv8Yo6G2XstMZ94UaPc9lVqWgzsM7W
el8dqV2AOqxCZ3LZlIAa/NnfloEdXl+JXyk9hu176jJ4BgfeV8N7HCvFzqBmNkD+RGJZcvxhlq2i
z/ddcKJnpXnow4OBurdWloltTy4hFmTxRdQZxu5Ygvv5tdy+To/8mikEam3eFi54uy33fKfqO0nz
VqcjxZTf6MJ2A8MZHt8Sw3C4hHcY6hORKAx575vOYpd+tsFUHGPveB3NuGq96d3Pug+RA2YaPGmT
S+MNRC3QFK1SbFMXGmHgewubkOhXXBqzJcdMdvNiNaDOe8KcJAJ9xwtvL4+WynRe8bnvcs4T+avr
ja1oTXp4nnwLFetjx7d54KoGhKHACGlpkzrlNR3ezyASGzkDiRGWdY1hCuqP1pZkTOmiUI/Q9LSV
C7hzp9bcezxuvaOOcGngfmZT7/COusVqbKiGwb81FTV7f1xFW4tsgzXWKxg0uk7xSeALmvG4k/I1
rEkmQ+9gJXGk+qjIuh7sG2M5gKcH2WGlg9+CUTT3Mcw3QhY+u7tIFimbv2h70bB+W6r9Bq+h50mv
pD/CUmeQWhRYvLcboa93ihQ39HUAIy/YV6LT2Vf2EmRKNRoQnf9wSUcrbW7r0eWBwnXKvIJtCoz6
QCOmxHaGY7ijcmO6TijdVVWwEo3qxgowviaRNOKp1IFzV4pXhhxiSImBLwPBDxcUS4FuRCgW4DTp
7Sz7WFc3fmpvDp3liCDis+6TGDeOBIfKAxfW1pnK8VSqrzvpynPRdybQhrJrcG0SAXXJLivac/xl
xLOFU6bHiC3hkyAo+hXGuFb0MwbGOpPUNtTvdiEhS6VBFkjAx/hdHBvgomHX2vwdCWPOs1sZzVFM
P5qT5M1aTtLIuk/0UjEMZDgF7laUQsXzSB4enfKRP78yLqJ70uhncGLfsLAIgdUY/7tiLleB1ZWV
nrqWbaFZNjSKX5Qq/HlOSvgPE1cU4h/QXnsOBnOhR8CZYK6RtvQNvgiQ4h+9r9CrR7xCRGKOmiyi
dGoNWRWuOGZ9MeW4wxp/zOT4rfY0d5dnXcb5OW5LUwXFcIDfyTjiY9NQCKoegGuEDwVi3D/Ipoxr
jaFI8fy3YFdkoWHlOGI3icIC1l4hR5GJwZYwWVWUMrpWfzJcxRLZGLlOkLbNAbtCCDlWDNyM43Gu
hHMmrDKPCTThc1VpK7gYbByqGfxFTcPjQ8/2kzJVwgrY1kfI8OdD7MoKQ0WjVkkZQqMQFNf4tFLe
tATSIaWNGfjxlNJ//ubFR5Vn7V7F9uMeXHY9kHnnSv9MS5lUAEgXbxW/R15k1Et72uZyThpyCdHX
jXd+yd9lUrG1m1Ol4JUWTu4UFc0xfn4WnbX/UUokXhikylmV5KpPZIWejBs4IBqmEPy8YlYqEPh8
HCEOHMRmpEmdzvmTCl3+fejy8/One26g8tXOwYRC7ufj6qfpSnkoQnGNNb+xlgACOKyBcpBo5aK2
Sgke/wYb7ie5houATbTNJwy8bB+kCdnQkjkZSs1uqEc2xJQIRp4CuKJjrOwmhXVyjfbCAC6zLz6p
oSLNkEKzkwFqiON3PHpIpe99Eb3BGMVlS6EPHBJ0+Sce37x1tPQfzwusHKxrhwTmOzubXaU3M4ZO
4d5RIYdMbkjHLGNnnepeYGy+RaDXr879TpWT+9JQfwahQJWG1Nrj+6Z7CnkN6HL/MTDfUZoQLFu8
AaVRCbJHQIkFcSX19KzHPGwO2hUiLsTve/84QHw1mv/K7RJqawIepEQXQ6aDQrCKuGPhKJEhRkPF
0uFmjyH1k48GR1bQLM9lz5g+A26w++O8sKfwvRTvFIJARvqDqT07ydUhdmmyOW2gn1YRkpElUOhi
FZoE/dUmLrBO9Y8hwtxbt84TbGH4MY0gDV3eXHKkdUTNdN8M2kjd5tPO+wvQRWBrOujlgBo7jwOX
UX5TKy/ZS7ZxPjOEdj1acW1NH6RnroPbGIQ1S8YeWTMjRLd5FoLBaS6BjiuycfM+0MIlqNKOC5zg
OTTXOvbB9vhwxDGFT+cVSe6C2H2Vdllpwxg0qznFWPSW4ag4tHoAy4w223LJD/Yqem0TicAzrT8s
Xy5zN/nEgZ9lkdL/VsUvLxICHkLaZIPDFkrxW23TpT+RoTGFuk5kSKgyF5mq69TeW15HUFhCr/xP
ZvVJLDxlIbljSkmMOMzeUmgsRHR2gG3rfhN65w8FMGY4mA5o4zCM9xvsQYL6UwDc9lprpb0cA/0P
TrkgCQ8TavyVSVq/NcPu9u7PgyPefHuVXQJerENu4B4TnSHpIsCObZ1WwM36jW1AyGU8Jo6iMSIQ
/A3yJ1+Hps6YC3vvtzjnHVgVvb6Pat/gHu9YvD7QBYalkgElgiHtjfXxl+HP7S+H+pESZgbgNRr/
5u6P8ETJyyt270R29l4K7yhe6TjTYLKCBCXQlRece/UCcjWh3qMWXxxTI5rtjtrES6Tsvl+jKN5a
XAHrNuL8OnM18ihElJQaTTe3MqKcom1WA087H1ZCD/bnNiZUN4+MCqUGuv0xltxex65SN6hN1zS6
wNx7gvuOEpshVgpf14FRHW5Y6stnBB1q+N8rajy3rQalIwxFh1XMtlv4t3PEPJD4PuMyKS7A47EL
cgxIqt/WvYpEl+hG04oXZsdCIy6Uuzryv
Bug #15930 Updated: gzencode can't have a level
ID: 15930 Updated by: [EMAIL PROTECTED] -Summary: gzencode can't have a level Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed -Bug Type: Zlib Related +Bug Type: Documentation problem Operating System: windows 200 PHP Version: 4.1.1 -Assigned To: +Assigned To: sr New Comment: That's an error in the documentation. The optional second parameter doesn't set the compression level, it does set the compression mode, i.e. you can use FORCE_GZIP or FORCE_DEFLATE in order to use gzip/deflate compression. The compression level is always the default Z_DEFAULT_COMPRESSION. If nobody objects (does anybody use this parameter?) I'll fix the documentation ... Previous Comments: [2002-03-07 07:37:05] [EMAIL PROTECTED] "; $gzdata = gzencode($data,9); echo strlen($gzdata),":bad always 10"; ?> -- Edit this bug report at http://bugs.php.net/?id=15930&edit=1
Bug #15930 Updated: gzencode can't have a level
ID: 15930 Updated by: [EMAIL PROTECTED] -Summary: gzencode can't have a level Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Documentation problem Operating System: windows 2000 PHP Version: 4.1.1 Assigned To: sr New Comment: Z_DEFAULT_COMPRESSION is a constant of the zlib include file, so you could change it only with a recompile of php. As a workaround maybe you can use gzdeflate() or gzcompress(), there the second parameter is the compression level. But then you have to manually add the gzip headers (and maybe the CRC) if you need them. Previous Comments: [2002-03-07 11:41:43] [EMAIL PROTECTED] YES, I use it. before I use gzopen($fic,"wb9"); with a temporary file the compression was better than gzencode. For passing information from serveur to client, the size of data is very important. I prefer spending 20 ms for much compression than 30 sec more for download. but if it is possible to change the Z_DEFAULT_COMPRESSION, it's ok I always use the same (maxi) compression. [2002-03-07 10:50:54] [EMAIL PROTECTED] That's an error in the documentation. The optional second parameter doesn't set the compression level, it does set the compression mode, i.e. you can use FORCE_GZIP or FORCE_DEFLATE in order to use gzip/deflate compression. The compression level is always the default Z_DEFAULT_COMPRESSION. If nobody objects (does anybody use this parameter?) I'll fix the documentation ... [2002-03-07 07:37:05] [EMAIL PROTECTED] "; $gzdata = gzencode($data,9); echo strlen($gzdata),":bad always 10"; ?> -- Edit this bug report at http://bugs.php.net/?id=15930&edit=1
Bug #14939 Updated: Warning: gzinflate: buffer error in /usr/local/apache/elca_rmg/class.FTemplateE
ID: 14939
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Zlib Related
Operating System: Apache
PHP Version: 4.1.1
-Assigned To:
+Assigned To: sr
New Comment:
Does the attached patch help?
--- /home/sr/cvs/php/php4/ext/zlib/zlib.c Thu Mar 7 16:38:26
2002
+++ ext/zlib/zlib.c Thu Mar 7 23:15:48 2002
@@ -967,7 +967,7 @@
if(! s2) { if(s1) efree(s1); RETURN_FALSE; }
stream.next_in = (Bytef*) Z_STRVAL_PP(data);
- stream.avail_in = (uInt) Z_STRLEN_PP(data);
+ stream.avail_in = (uInt) Z_STRLEN_PP(data) + 1; /*
there is room for \0 */
stream.next_out = s2;
stream.avail_out = (uInt) length;
(If there are broken line breaks and you can't apply it, change the
line stream.avail_in = (uInt) Z_STRLEN_PP(data) to ...(data)+1 in the
gzinflate function).
Please report if it works (and if it doesn't break other things). This
seems to be a rather strange thing in the zlib library ...
Previous Comments:
[2002-03-07 08:06:33] [EMAIL PROTECTED]
Does this script work if you don't provide a compression level?
-- robin
[2002-01-08 21:04:16] [EMAIL PROTECTED]
Receive the following error with only 15 consecutive characters
entered.
Warning: gzinflate: buffer error in
/usr/local/apache/elca_rmg/class.FTemplateExt.php on line 153
What follows is the code updating the SQL files:
$gzsize = strlen($description) + 4; // added 4 more than req'd
$gzcompress = gzdeflate ($description,6);
$gzcompress = addslashes($gzcompress); //Reqd for SQL updates
$query = "UPDATE htmlcontent SET record_nbr = \"$record_nbr\",
gzcompress = \"$gzcompress\", gzsize = $gzsize WHERE record_nbr =
\"$record_nbr\"";
}
general_update($errno,$errmsg,$rowsaffected, $result, $s_synod_id,
$query); // UPDATE the record
***
Next I attempt to read the record back and unzip gzcompress
Note that $description consists of 20 'a' characters. Any repetitive
char will do and only 15 to 20 are req'd
***
$query = "SELECT * FROM htmlcontent WHERE record_nbr =
\"$record_nbr\"";
general_read($errno, $errmsg,$numrows, $result_html, $s_synod_id,
$query);
if ($numrows > 0) {
if ($row_html = mysql_fetch_array ($result_html)) {
$content = stripslashes($row_html["gzcompress"]);
if (strlen($content) > 0) {
**Error occurs on the following instruction*
$new = gzinflate($content,$row_html["gzsize"]);
--
Edit this bug report at http://bugs.php.net/?id=14939&edit=1
Bug #14939 Updated: Warning: gzinflate: buffer error in /usr/local/apache/elca_rmg/class.FTemplateE
ID: 14939
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Closed
Bug Type: Zlib Related
Operating System: Apache
PHP Version: 4.1.1
Assigned To: sr
New Comment:
Should be fixed in latest cvs version.
Previous Comments:
[2002-03-07 17:24:45] [EMAIL PROTECTED]
Does the attached patch help?
--- /home/sr/cvs/php/php4/ext/zlib/zlib.c Thu Mar 7 16:38:26
2002
+++ ext/zlib/zlib.c Thu Mar 7 23:15:48 2002
@@ -967,7 +967,7 @@
if(! s2) { if(s1) efree(s1); RETURN_FALSE; }
stream.next_in = (Bytef*) Z_STRVAL_PP(data);
- stream.avail_in = (uInt) Z_STRLEN_PP(data);
+ stream.avail_in = (uInt) Z_STRLEN_PP(data) + 1; /*
there is room for \0 */
stream.next_out = s2;
stream.avail_out = (uInt) length;
(If there are broken line breaks and you can't apply it, change the
line stream.avail_in = (uInt) Z_STRLEN_PP(data) to ...(data)+1 in the
gzinflate function).
Please report if it works (and if it doesn't break other things). This
seems to be a rather strange thing in the zlib library ...
[2002-03-07 08:06:33] [EMAIL PROTECTED]
Does this script work if you don't provide a compression level?
-- robin
[2002-01-08 21:04:16] [EMAIL PROTECTED]
Receive the following error with only 15 consecutive characters
entered.
Warning: gzinflate: buffer error in
/usr/local/apache/elca_rmg/class.FTemplateExt.php on line 153
What follows is the code updating the SQL files:
$gzsize = strlen($description) + 4; // added 4 more than req'd
$gzcompress = gzdeflate ($description,6);
$gzcompress = addslashes($gzcompress); //Reqd for SQL updates
$query = "UPDATE htmlcontent SET record_nbr = \"$record_nbr\",
gzcompress = \"$gzcompress\", gzsize = $gzsize WHERE record_nbr =
\"$record_nbr\"";
}
general_update($errno,$errmsg,$rowsaffected, $result, $s_synod_id,
$query); // UPDATE the record
***
Next I attempt to read the record back and unzip gzcompress
Note that $description consists of 20 'a' characters. Any repetitive
char will do and only 15 to 20 are req'd
***
$query = "SELECT * FROM htmlcontent WHERE record_nbr =
\"$record_nbr\"";
general_read($errno, $errmsg,$numrows, $result_html, $s_synod_id,
$query);
if ($numrows > 0) {
if ($row_html = mysql_fetch_array ($result_html)) {
$content = stripslashes($row_html["gzcompress"]);
if (strlen($content) > 0) {
**Error occurs on the following instruction*
$new = gzinflate($content,$row_html["gzsize"]);
--
Edit this bug report at http://bugs.php.net/?id=14939&edit=1
Bug #15930 Updated: gzencode can't have a level
ID: 15930 Updated by: [EMAIL PROTECTED] -Summary: gzencode can't have a level Reported By: [EMAIL PROTECTED] -Status: Analyzed +Status: Closed Bug Type: Documentation problem Operating System: windows 2000 PHP Version: 4.1.1 Assigned To: sr New Comment: Fixed in latest cvs. Previous Comments: [2002-03-07 13:04:09] [EMAIL PROTECTED] Well, I prefer the fonctionnality in documentation or something like : gzencode($data[,$level[,$mode]]) It would be much easy to use, than make a gzip by hand with header,crc, ... in "User Contributed Notes" two another persons report this problem. We can perhaps ask them. [2002-03-07 12:42:03] [EMAIL PROTECTED] Z_DEFAULT_COMPRESSION is a constant of the zlib include file, so you could change it only with a recompile of php. As a workaround maybe you can use gzdeflate() or gzcompress(), there the second parameter is the compression level. But then you have to manually add the gzip headers (and maybe the CRC) if you need them. [2002-03-07 11:41:43] [EMAIL PROTECTED] YES, I use it. before I use gzopen($fic,"wb9"); with a temporary file the compression was better than gzencode. For passing information from serveur to client, the size of data is very important. I prefer spending 20 ms for much compression than 30 sec more for download. but if it is possible to change the Z_DEFAULT_COMPRESSION, it's ok I always use the same (maxi) compression. [2002-03-07 10:50:54] [EMAIL PROTECTED] That's an error in the documentation. The optional second parameter doesn't set the compression level, it does set the compression mode, i.e. you can use FORCE_GZIP or FORCE_DEFLATE in order to use gzip/deflate compression. The compression level is always the default Z_DEFAULT_COMPRESSION. If nobody objects (does anybody use this parameter?) I'll fix the documentation ... [2002-03-07 07:37:05] [EMAIL PROTECTED] "; $gzdata = gzencode($data,9); echo strlen($gzdata),":bad always 10"; ?> -- Edit this bug report at http://bugs.php.net/?id=15930&edit=1
#16109 [Csd]: zlib.output_compression and generated pictures
ID: 16109 Updated by: [EMAIL PROTECTED] Reported By: pguillot at paanjaru dot com Status: Closed Bug Type: Zlib Related Operating System: linux PHP Version: 4.1.2 New Comment: The change was committed to CVS July 2002, I think the first release with it was 4.3. Previous Comments: [2003-03-22 14:10:28] phpuser at dpiworld dot com What version will this fix show up in? I have php 4.1.2 and cannot successfully turn off output_compression in my image display script. At least it makes no difference. I also specify a correct header for Content-Type: image/jpeg, yet that fix also does not seem effective. Internet Explorer 6.x (all patches installed) delays display of image data sent by my script for about 20 seconds or more and then they suddenly appear. Had to turn off zlib.output_compression for entire domain due to this problem, and images are displayed normally again. [2002-07-28 10:20:56] [EMAIL PROTECTED] Should be fixed in latest CVS. Now pages with image/ content-type header aren't compressed and you can use ini_set with zlib.output_compression during script execeution (before the headers are sent). [2002-07-03 01:00:09] php-bugs at lists dot php dot net No feedback was provided for this bug for over a month, 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". [2002-06-02 17:41:53] [EMAIL PROTECTED] Are you sure mod_gzip compresses the pictures? Try to explicitly configure mod_gzip to compress images and please give us feedback if they work with your Netscape. I did a short test here and they also didn't work, so it seems really a Netscape problem. Other test: Does it work if you switch of zlib.output_compression and instead compress the page via mod_gzip? [2002-05-29 03:54:17] php at fatalfx dot com Here's a short reproducing example script. Since the two pictures on the php info page are "generated" (inline) the script is very short: Make sure your zlib.output_compression = On and you use Netscape Communicator 4.79 (Maybe the "bug" is in other Netscape version too but in 4.79 it is for sure). Roger The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/16109 -- Edit this bug report at http://bugs.php.net/?id=16109&edit=1
#25218 [Opn->Csd]: PHP sends back invalid deflate data
ID: 25218 Updated by: [EMAIL PROTECTED] Reported By: amb at gedanken dot demon dot co dot uk -Status: Open +Status: Closed Bug Type:Zlib Related PHP Version: 4CVS-2003-08-23 (stable) New Comment: Thank you for the report, I fixed it in PHP5 CVS, can you try if this works for you? Because there can be some browser issues, I think it should be tested with PHP5 before the patch goes into the PHP4 branch. Previous Comments: [2003-08-23 06:09:35] amb at gedanken dot demon dot co dot uk Description: When PHP sends back data using the deflate method it incorrectly puts a gzip style header before it. I sent this request GET / HTTP/1.0 User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020623 Debian/1.2.5-0.woody.1 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1 Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 Keep-Alive: 300 Host: bugs.php.net Connection: close Accept-Encoding: x-deflate; q=0.9, deflate; q=0.9, identity; q=0.1 to bugs.php.net and got this reply header HTTP/1.1 200 OK Date: Sat, 23 Aug 2003 11:00:34 GMT Server: Apache/1.3.27 (Unix) PHP/4.3.0 X-Powered-By: PHP/4.3.0 Content-Encoding: deflate Vary: Accept-Encoding Connection: close Content-Type: text/html with this data (converted to hex format by 'od -x') 000 8b1f 0008 0300 9c78 58cc 6fdd 020 36db 7f10 feae 038a b587 892f 2765 b643 The first 10 bytes are a valid gzip header (RFC1952), the following 2 bytes are a valid zlib header (RFC1950), the following bytes are valid deflate data (RFC1951). The first 10 bytes should not be sent. -- Edit this bug report at http://bugs.php.net/?id=25218&edit=1
#25224 [Opn->Fbk]: gzuncompress problem
ID: 25224
Updated by: [EMAIL PROTECTED]
Reported By: r dot staribacher at hypermove dot com
-Status: Open
+Status: Feedback
Bug Type: Zlib Related
Operating System: windows 2000/xp
PHP Version: 4.3.2
New Comment:
Can you provide a self-contained example without this pdf class and
with concrete data? Maybe save and base64_encode the data which should
be gzuncompress()ed.
Also "1" isn't a good choice for the optional length parameter to
gzuncompress() if you want more than a single character. This parameter
contains the maximal expected length of the uncompressed data.
Previous Comments:
[2003-08-24 13:00:12] r dot staribacher at hypermove dot com
Description:
error occured on:
OS: windows 2000 and xp
webserver: apache and iis
I am using a PHP class for reading pdf files. this class uses
gzuncompress which causes problems on windows. IE displays the message
"action canceled". Under Linux it "seems" to work. Parsing a large
amount of pdf files also causes the process to stop.
I have seen the Bug #20535: zLib crashes when trying to gzuncompress.
So I tried to solve the problem using the optional length parameter.
That didn't solve the problem.
you can see or download the class on:
http://www.phpclasses.org/browse.html/package/702.html
I tried also xpdf (pdftotext.exe) to read PDFs using exec(), but
another problem (unable to fork ...) occured! But this is not part of
my bug report, but also annoying.
One question:
We can create PDFs using PHP! Why can't we read PDFs using PHP? It
should be easier reading them instead of creating them?
php.ini settings:
savemode = off
magic quotes = off
no additional modules are activated (gzip is already compiled into php
4.3)
Reproduce code:
---
function nextline()
{
$pos = strpos($this->_buffer, "\r");
if ($pos === false)
{
return false;
}
$line = substr($this->_buffer, 0, $pos);
$this->_buffer = substr($this->_buffer, $pos + 1);
if ($line == "stream")
{
$endpos = strpos($this->_buffer, "endstream");
$stream = substr($this->_buffer, 1, $endpos - 1);
$stream = gzuncompress($stream,1);
$this->_buffer = $stream . substr($this->_buffer, $endpos + 9);
}
return $line;
}
Expected result:
The code will return an integer (how many times is the search
expression in the pdf document).
The original class returns true (found search expression) othewise
false I think!
--
Edit this bug report at http://bugs.php.net/?id=25224&edit=1
#25218 [Csd]: PHP sends back invalid deflate data
ID: 25218 Updated by: [EMAIL PROTECTED] Reported By: amb at gedanken dot demon dot co dot uk Status: Closed Bug Type:Zlib Related PHP Version: 4CVS-2003-08-23 (stable) New Comment: It's now fixed in the PHP_4_3 cvs branch, too, so with a new snapshot it should work. Sorry, I don't know any site to test for you (yet ...). Previous Comments: [2003-08-28 00:16:10] amb at gedanken dot demon dot co dot uk I don't use PHP myself, so I can't test the new version unless there is a web site that is using it somewhere that I can test my client with. [2003-08-24 09:10:37] [EMAIL PROTECTED] Thank you for the report, I fixed it in PHP5 CVS, can you try if this works for you? Because there can be some browser issues, I think it should be tested with PHP5 before the patch goes into the PHP4 branch. [2003-08-23 06:09:35] amb at gedanken dot demon dot co dot uk Description: When PHP sends back data using the deflate method it incorrectly puts a gzip style header before it. I sent this request GET / HTTP/1.0 User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020623 Debian/1.2.5-0.woody.1 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1 Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 Keep-Alive: 300 Host: bugs.php.net Connection: close Accept-Encoding: x-deflate; q=0.9, deflate; q=0.9, identity; q=0.1 to bugs.php.net and got this reply header HTTP/1.1 200 OK Date: Sat, 23 Aug 2003 11:00:34 GMT Server: Apache/1.3.27 (Unix) PHP/4.3.0 X-Powered-By: PHP/4.3.0 Content-Encoding: deflate Vary: Accept-Encoding Connection: close Content-Type: text/html with this data (converted to hex format by 'od -x') 000 8b1f 0008 0300 9c78 58cc 6fdd 020 36db 7f10 feae 038a b587 892f 2765 b643 The first 10 bytes are a valid gzip header (RFC1952), the following 2 bytes are a valid zlib header (RFC1950), the following bytes are valid deflate data (RFC1951). The first 10 bytes should not be sent. -- Edit this bug report at http://bugs.php.net/?id=25218&edit=1
#23488 [Csd]: zlib output compression clobbers user-supplied Vary: header
ID: 23488 Updated by: [EMAIL PROTECTED] Reported By: m at mlcastle dot net Status: Closed Bug Type: Feature/Change Request Operating System: GNU/Linux 2.2.25 PHP Version: 4.3.1 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Sorry, the first fix was only for ob_gzhandler, but now it should be fixed for zlib.output_compression, too. Previous Comments: [2003-08-02 11:11:36] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-08-02 11:08:02] [EMAIL PROTECTED] Same as bug #24827 [2003-05-05 05:52:41] [EMAIL PROTECTED] This issue has long been recognised since zlib.compression feature was implemented. The behaviour is quite expected => marking this as a feature request. [2003-05-05 04:44:46] m at mlcastle dot net If zlib.output_compression is on, then it (sensibly) sends a Vary: Accept-Encoding header to the browser. However, if the user's script has sent its own Vary: header, then that header will get clobbered by zlib's. Better solutions would be to either: * let the user's header take preference, and caution the user to include Accept-Encoding in the custom one, or * magically combine the user's header and the zlib one. Refernece: RFC 2616 (HTTP/1.1 Spec), Section 14.44 Sample script: -- Edit this bug report at http://bugs.php.net/?id=23488&edit=1
#19436 [Opn->Fbk]: zlib.output_compression causing corruption
ID: 19436 Updated by: [EMAIL PROTECTED] Reported By: steveh at brendata dot co dot uk -Status: Open +Status: Feedback Bug Type: Zlib Related Operating System: redhat linux 7.3 -PHP Version: 4CVS-2002-09-16 +PHP Version: 4.3.3 New Comment: Does it work without the Zend Optimiser? If the file is still corrupted after turning off Zend Optimiser, can you give us a short self contained example php script (and a file) which shows the error? Thank you! Previous Comments: [2003-09-17 11:58:11] steveh at brendata dot co dot uk Should also mention that this is with the latest version of the zend optimiser as well. [2003-09-17 11:57:26] steveh at brendata dot co dot uk Still a problem with 4.3.3 [2003-02-20 07:58:59] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-02-12 23:56:40] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip And disable the Zend Optimizer.. [2003-01-24 10:45:02] steveh at brendata dot co dot uk Any news? Is it worth trying this again on the latest CVS? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/19436 -- Edit this bug report at http://bugs.php.net/?id=19436&edit=1
#33525 [NEW]: __autoload() for interfaces and functions
From: sr at brightlight dot ch
Operating system: Irrelevant
PHP version: 5.0.4
PHP Bug Type: Feature/Change Request
Bug description: __autoload() for interfaces and functions
Description:
__autoload() is very nice, but classes are not the only
problem.
Please add a parameter $type to allow functions and interfaces
become autoloaded as well.
Even more convenient if there were not only the types 'class',
'interface' and 'function', but also 'method' to autoload
methods of classes.
Example given.
Reproduce code:
---
function __autoload($name, $type)
{
// $type would be 'class', 'interface', 'function' or 'method'
require_once("$type.$name.inc");
}
--
Edit bug report at http://bugs.php.net/?id=33525&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33525&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33525&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33525&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33525&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33525&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33525&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33525&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33525&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33525&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33525&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33525&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33525&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33525&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33525&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33525&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33525&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33525&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33525&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33525&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33525&r=mysqlcfg
#6932 [Com]: Filesize / File_exists and include_path
ID: 6932 Comment by: sr at brightlight dot ch Reported By: richard dot heyes at heyes-computing dot net Status: Open Bug Type: Feature/Change Request Operating System: Any PHP Version: 4.0.2 New Comment: I second this request. Open since 5 years, since PHP5's autoload even more important and not even yet assigned... :-/ Previous Comments: [2002-06-04 09:13:56] [EMAIL PROTECTED] Any objection not to add this? [2001-08-12 16:32:09] [EMAIL PROTECTED] Maybe I should clarify, it was the filesize and file_exists function I was hoping would be updated to have an optional argument so they would check the include_path. [2001-08-12 16:00:53] [EMAIL PROTECTED] That's nice. Doesn't solve the feature request though. [2001-08-12 15:25:02] [EMAIL PROTECTED] according to the docs: int fopen (string filename, string mode [, int use_include_path]) [2000-09-29 02:08:42] richard dot heyes at heyes-computing dot net Currently filesize and file_exists (possibly other, these are two I know of) don't appear to support an extra argument like fopen does to make use of the include_path. So the following code would fail if the file is in the include_path: $file = fread($fp = fopen($filename, 'r', 1), filesize($filename)); fclose($fp); -- Edit this bug report at http://bugs.php.net/?id=6932&edit=1
#33528 [NEW]: get_include_path returning an array
From: sr at brightlight dot ch Operating system: Irrelevant PHP version: 4.3.11 PHP Bug Type: Feature/Change Request Bug description: get_include_path returning an array Description: get_include_path is basically useless like it is now (get_ini can be used for that as well). It would be more useable if it returned an array of include paths, so that we don't always have to split it up by ourselfs which is time consuming and not elegant. -- Edit bug report at http://bugs.php.net/?id=33528&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33528&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33528&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33528&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33528&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33528&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33528&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33528&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33528&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33528&r=support Expected behavior: http://bugs.php.net/fix.php?id=33528&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33528&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33528&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33528&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33528&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33528&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33528&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33528&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33528&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33528&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33528&r=mysqlcfg
#33525 [Csd]: __autoload() for interfaces and functions
ID: 33525
User updated by: sr at brightlight dot ch
Reported By: sr at brightlight dot ch
Status: Closed
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 5.*
New Comment:
Yes, it works for interfaces, but you don't know whether you
autoload an interface or a class.
This plays a role when you have a naming scheme which
differs for classes and interfaces. Since interfaces are
many to many it makes sense to place interfaces in separate
files and a naming scheme is never bad idea.
E.g. I have a naming scheme interface.{name}.inc and class.
{name}.inc
Functions: why not? Is it a technical reason? Or you just
don't like the idea?
Previous Comments:
[2005-06-30 20:44:32] [EMAIL PROTECTED]
It already works for Interfaces.
And it will never work for functions.
[2005-06-30 16:49:02] sr at brightlight dot ch
Description:
__autoload() is very nice, but classes are not the only
problem.
Please add a parameter $type to allow functions and interfaces
become autoloaded as well.
Even more convenient if there were not only the types 'class',
'interface' and 'function', but also 'method' to autoload
methods of classes.
Example given.
Reproduce code:
---
function __autoload($name, $type)
{
// $type would be 'class', 'interface', 'function' or 'method'
require_once("$type.$name.inc");
}
--
Edit this bug report at http://bugs.php.net/?id=33525&edit=1
#50559 [NEW]: Clone is not implemented for DateInterval and DatePeriod
From: sr at emini dot dk
Operating system: Fedora 10
PHP version: 5.3.1
PHP Bug Type: Date/time related
Bug description: Clone is not implemented for DateInterval and DatePeriod
Description:
I am unable to clone an object of type DateInterval or DatePeriod. The
clone appears to be an empty object.
I've looked in the source and the code to clone the objects seem to be
missing from both date_object_clone_interval() and
date_object_clone_period().
Reproduce code:
---
$dateInterval1 = new \DateInterval('P1D');
$dateInterval2 = clone $dateInterval;
var_dump($dateInterval1);
var_dump($dateInterval2);
Expected result:
$dateInterval2 should be a clone of $dateInterval1.
Actual result:
--
$dateInterval1 works as expected, but $dateInterval2 appears to be an
empty object.
--
Edit bug report at http://bugs.php.net/?id=50559&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50559&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50559&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50559&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50559&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50559&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50559&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50559&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50559&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50559&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50559&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50559&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50559&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50559&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50559&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50559&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50559&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50559&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50559&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50559&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50559&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50559&r=mysqlcfg
#33856 [NEW]: $this shining through
From: sr at brightlight dot ch
Operating system: Mac OS X 10.4.1
PHP version: 5.0.4
PHP Bug Type: Class/Object related
Bug description: $this shining through
Description:
If a method is called via object::method(); from within a
class method, then inside of the object::method(); the $this
from the calling class method is visible.
This makes it almost impossible to tell if a method was
invoked via -> or ::
Reproduce code:
---
test();
class testclass {
function test() {
otherclass::staticFunction();
normalFunction();
}
}
class otherclass {
function staticFunction() {
echo "staticFunction: ".(isset($this) ? "set and of
class:
".get_class($this)."\n" : "not set\n");
}
}
function normalFunction() {
echo "normalFunction: ".(isset($this) ? "set and of class:
".get_class($this)."\n" : "not set\n");
}
?>
Expected result:
staticFunction: not set
normalFunction: not set
Actual result:
--
staticFunction: set and of class: testclass
normalFunction: not set
--
Edit bug report at http://bugs.php.net/?id=33856&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33856&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33856&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33856&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33856&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33856&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33856&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33856&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33856&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33856&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33856&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33856&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33856&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33856&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33856&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33856&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33856&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33856&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33856&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33856&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33856&r=mysqlcfg
#33857 [NEW]: token_get_all() inconsistent results?
From: sr at brightlight dot ch Operating system: Mac OS X 10.4.1 PHP version: 5.0.4 PHP Bug Type: Unknown/Other Function Bug description: token_get_all() inconsistent results? Description: Obviously the same problem as in Bug #33093, which is set to bogus (no comment). When I tokenize the very same code over and over again I happen to get different tokens. About 9 times out of 10 I get: Token'<', Token '?', Token T_STRING 'php', Token T_WHITESPACE '\n', About 1 time out of 10 Times I get Token T_OPEN_TAG 'http://bugs.php.net/?id=33857&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33857&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33857&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33857&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33857&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33857&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33857&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33857&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33857&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33857&r=support Expected behavior: http://bugs.php.net/fix.php?id=33857&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33857&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33857&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33857&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33857&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33857&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33857&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33857&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33857&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33857&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33857&r=mysqlcfg
#33856 [Bgs]: $this shining through
ID: 33856
User updated by: sr at brightlight dot ch
Reported By: sr at brightlight dot ch
Status: Bogus
Bug Type: Class/Object related
Operating System: *
PHP Version: 5.*
New Comment:
Well, maybe it is not intended that way anymore, but as long
as calling a function that way does not result in an error-
message it should be done correctly. A function opens a new
scope and within that scope, $this should not be visible (as
any other variable from the calling scope).
It is clear to me that this problem does not appear for pure
static functions, but I happen to have some hybrid
functions, that's why I discovered this problem at all.
But a question besides this: if calling via :: is only
possible with static functions in future - is there still a
way for developing hybrid functions that can be called
either via -> or :: or is the only possible solution to have
two different functions for the same?
Previous Comments:
[2005-07-25 23:50:51] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Mark the function as static. It is only possible to call non static
methods as static methods for BC reasons.
[2005-07-25 23:46:58] sr at brightlight dot ch
Description:
If a method is called via object::method(); from within a
class method, then inside of the object::method(); the $this
from the calling class method is visible.
This makes it almost impossible to tell if a method was
invoked via -> or ::
Reproduce code:
---
test();
class testclass {
function test() {
otherclass::staticFunction();
normalFunction();
}
}
class otherclass {
function staticFunction() {
echo "staticFunction: ".(isset($this) ? "set and of
class:
".get_class($this)."\n" : "not set\n");
}
}
function normalFunction() {
echo "normalFunction: ".(isset($this) ? "set and of class:
".get_class($this)."\n" : "not set\n");
}
?>
Expected result:
staticFunction: not set
normalFunction: not set
Actual result:
--
staticFunction: set and of class: testclass
normalFunction: not set
--
Edit this bug report at http://bugs.php.net/?id=33856&edit=1
#33586 [Com]: Serialization breaks references
ID: 33586
Comment by: sr at brightlight dot ch
Reported By: wmeler at wp dot pl
Status: Assigned
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5CVS-2005-07-06
Assigned To: dmitry
New Comment:
I experienced a similar problem. An even simpler setup
already breaks unserialisation (php 5.0.4):
$rec= array('rec' => 'x');
$rec['rec']= &$rec;
echo "print_r:\n".print_r($rec, true);
echo "\nafter unserialisation:\n".print_r(unserialize
(serialize($rec)), true);
The output will be:
print_r:
Array
(
[rec] => Array
*RECURSION*
)
after unserialisation:
Array
(
[rec] => Array
(
[rec] =>
)
)
With a few more dimensions before the recursion php will
even crash on OS X 10.4.1
regards
Previous Comments:
[2005-07-22 08:52:12] wmeler at wp dot pl
Do you want simplest to debug example or complicated real world
example?
How about this :
outputs remain the same
you can even substitute 'c' with 'parent' and 'd' with 'child' which
makes it more real but this would change outputs
[2005-07-22 01:03:09] [EMAIL PROTECTED]
In your example you're making a reference to a non-existing variable.
Please come up with something more realistic.
[2005-07-06 12:51:21] wmeler at wp dot pl
I've tried - nothing changed
[2005-07-06 12:17:00] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-07-06 12:03:59] wmeler at wp dot pl
Description:
After serializing variable with circular reference you get 2 copies of
root variable.
Look at output of reproduce code - var_dump outputs should be the same
but they are not.
for code:
$c['d2']=&$d;
$d['c2']=&$c;
echo serialize($c);
you get
a:1:{s:2:"d2";a:1:{s:2:"c2";a:1:{s:2:"d2";R:2;}}}
I think that it should be something like
a:1:{s:2:"d2";a:1:{s:2:"c2";R:1;}}
Reproduce code:
---
&array(1) {
["c2"]=>
&array(2) {
["d2"]=>
&array(1) {
["c2"]=>
&array(2) {
["d2"]=>
*RECURSION*
["x"]=>
string(1) "x"
}
}
["x"]=>
string(1) "x"
}
}
["x"]=>
string(1) "x"
}
array(2) {
["d2"]=>
&array(1) {
["c2"]=>
&array(2) {
["d2"]=>
&array(1) {
["c2"]=>
&array(2) {
["d2"]=>
*RECURSION*
["x"]=>
string(1) "x"
}
}
["x"]=>
string(1) "x"
}
}
["x"]=>
string(1) "x"
}
Actual result:
--
array(2) {
["d2"]=>
&array(1) {
["c2"]=>
&array(2) {
["d2"]=>
&array(1) {
["c2"]=>
&array(2) {
["d2"]=>
*RECURSION*
["x"]=>
string(1) "x"
}
}
["x"]=>
string(1) "x"
}
}
["x"]=>
string(1) "x"
}
array(2) {
["d2"]=>
&array(1) {
["c2"]=>
array(1) {
["d2"]=>
&array(1) {
["c2"]=>
array(1) {
["d2"]=>
*RECURSION*
}
}
}
}
["x"]=>
string(1) "x"
}
--
Edit this bug report at http://bugs.php.net/?id=33586&edit=1
