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

go to bug id or search bugs for

Bug #80953 gzencode(): stream error
Submitted: 2021-04-12 17:49 UTC Modified: 2021-08-16 15:10 UTC
Votes:4
Avg. Score:4.0 ± 1.0
Reproduced:3 of 3 (100.0%)
Same Version:3 (100.0%)
Same OS:2 (66.7%)
From: tessus@php.net Assigned:
Status: Open Package: Zlib related
PHP Version: 7.4.16 OS: Linux
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: tessus@php.net
New email:
PHP Version: OS:

 

 [2021-04-12 17:49 UTC] tessus@php.net 
Description:
------------
I've tested it with PHP 7.4.15 and PHP 7.4.16.

I get errors with zlib related functions. e.g. for the test script below, I get the following warning, which should be an error in the first place, because the resulting file is invalid.

PHP Warning:  gzencode(): stream error in t.php on line 3

It happens with cli and php-fpm. I do have read/write access to the directory where the file bigfile.txt is located.

I've tested this with 7.3.27 and it works without issues. I compile PHP myself and there were no errors in config.log, nor during compilation. configure stated for both PHP releases that zlib was found and ok to use.

Test script:
---------------
<?php
$data = implode("", file("bigfile.txt"));
$gzdata = gzencode($data, 9);
$fp = fopen("bigfile.txt.gz", "w");
fwrite($fp, $gzdata);
fclose($fp);
?>

Expected result:
----------------
The file should be compressed and the result should be a valid bigfile.txt.gz

Actual result:
--------------
A file bigfile.txt.gz is created with 0 bytes.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2021-04-13 11:14 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2021-04-13 11:14 UTC] cmb@php.net 
> PHP Warning:  gzencode(): stream error in t.php on line 3

This is apparently caused by deflateInit2()[1] returning
Z_STREAM_ERROR.  The zlib manual[2] states:

| deflateInit2 returns Z_OK if success, Z_MEM_ERROR if there was
| not enough memory, Z_STREAM_ERROR if a parameter is invalid (such
| as an invalid method), or Z_VERSION_ERROR if the zlib library
| version (zlib_version) is incompatible with the version assumed by
| the caller (ZLIB_VERSION).

Does zlib_version() match ZLIB_VERSION for you?

[1] <https://github.com/php/php-src/blob/php-7.4.16/ext/zlib/zlib.c#L346>
[2] <https://zlib.net/manual.html>
 [2021-04-13 15:58 UTC] tessus@php.net 
zlib_version() tells me undefined function in the php shell. But:

php > echo ZLIB_VERSION;
1.2.8

But then I looked at the phpinfo() output and found something very strange:

ZLib Support => enabled
Stream Wrapper => compress.zlib://
Stream Filter => zlib.inflate, zlib.deflate
Compiled Version => 1.2.8
Linked Version => 1.1.3

My zlib version on the system is 1.2.8. There is nowhere a 1.1.3 in any of my lib directories.
And on PHP 7.3 both match and say 1.2.8.

I can assure you that there is no 1.1.3 of zlib on my system and I have no idea where this is coming from. ldd for my php 7.4 binary shows:

libz.so.1 => /usr/lib64/libz.so.1 (0x00000036d3200000)

and ls -la /usr/lib64/libz.so.1 shows: /usr/lib64/libz.so.1 -> libz.so.1.2.8

I just compiled 7.3 again and all works. I compile 7.4 and same problem. It's very puzzling, since I certainly haven't installed libz 1.1.3, nor is it present in any of my lib paths. (Why would I install an older version?) Also, in that case 7.3, would pick it up too.

We have a mystery on our hands.

The only logical explanation would be that PHP 7.4 bundles 1.1.3 and statically links it.
 [2021-04-13 16:45 UTC] cmb@php.net 
> zlib_version() tells me undefined function in the php shell.

Oh indeed, the proper spelling is zlibVersion(), and that function
is used to retrieve the linked version[1].  To my knowlege, PHP does
not (and never did) bundle zlib, so this old version must be somewhere
on your system.  I assume that the difference between PHP 7.3 and 7.4
is due to build system changes; 7.4 uses pkg-config to detect zlib[2]
while 7.3 manually searched for the lib in the usual places[3].

Anyhow, what does

    pkg-config --print-provides zlib

report?

[1] <https://github.com/php/php-src/blob/php-7.4.16/ext/zlib/zlib.c#L1593>
[2] <https://github.com/php/php-src/blob/php-7.4.16/ext/zlib/config0.m4>
[3] <https://github.com/php/php-src/blob/php-7.3.27/ext/zlib/config0.m4>
 [2021-04-13 20:27 UTC] tessus@php.net 
Hmmm, still not working, but we got the output from phpinfo anyway.

php > echo zlibVersion();
PHP Warning:  Uncaught Error: Call to undefined function zlibVersion() in php shell code:1

The output from pkgconfig looks ok:

# pkg-config --print-provides zlib
zlib = 1.2.8
 [2021-04-13 21:56 UTC] cmb@php.net
-Status: Feedback +Status: Open -Assigned To: cmb +Assigned To:
 [2021-04-13 21:56 UTC] cmb@php.net 
> php > echo zlibVersion();

zlibVersion() is a C function. :)

> The output from pkgconfig looks ok:

Yes.  However, I assume that the old zlib version is somewhere in
your LD_LIBRARY_PATH, or so.  Sorry, I'm usually working on
Windows, so I can't help any further, but I don't think this is a
PHP bug.
 [2021-04-13 22:17 UTC] tessus@php.net 
Hmm, you didn't tell me that is was a c function. Just from looking at the name I can't determine that. Anyway, we got the proper output from phpinfo().

I haven't found it in LD_LIBRARY_PATH. I'm running Fedora 20 and haven't updated any yum packages for more than 4 years, because I compile everything myself anyway. And I do know that I haven't installed nor compilled 1.1.3 ever.

I really have no idea where this should be coming from. I'll try to replace the config.m4 with the one from 7.3. Let's see if that works.
 [2021-04-15 17:29 UTC] tessus@php.net 
Ok, so replacing the config0.m4 on 7.4 with the one from 7.3 didn't help. Same problem. It's still working in 7.3 though.

I ran `find . -name libz.so.1.1.3` in / and guess what. There's no 1.1.3 library on my entire system. I really have no idea what the issue is. It just doesn't make any sense.

My server uptime has been 2390 days, so I will be migrating to a new machine soon. Maybe that will fix the issues.
 [2021-05-05 20:18 UTC] Albert dot sailer at gmail dot com 
Hi,

Could you solve this Problem?
Im having the same issue on SuSE.
 [2021-05-05 20:45 UTC] tessus@php.net 
Nope, but I am in the process of setting up a new server. Still not sure if it's gonna help though, since as mentioned before there is no version 1.1.3 anywhere on my system.

I also do not have the problem with PHP 7.3. It's specfic to PHP 7.4. But apparently that's not enough for the devs to look into it.
 [2021-05-06 03:11 UTC] tessus@php.net 
Stop spamming this bug rtrtrtrtrt, unless you have anything useful to say. Somehow you don't understand that some servers are not rebooted which means there can't be a system update.

With all your ignorant comments you missed one simple fact: there's no version 1.1.3 on my system. But I guess you are as puzzled as me, how PHP can report zlib 1.1.3 on a system that does not have a libz.so.1.1.3.

I know it is not the best situation. I compile all outward facing services and dependencies myself. I have about 10,000 attacks on that server per day. And in 6 years, nobody broke that thing, not even with DOS attacks. So please, go annoy someone else.

So unless you can tell me why PHP 7.3 compiles with 1.2.8 and PHP 7.4 with 1.1.3, even though there's no libz.so.1.1.3 on that machine (nor a static version of libz), stop wasting my time with your useless comments.
 [2021-05-06 04:00 UTC] tessus@php.net 
Name calling. Really mature.

> and no downtimes longer than 5-15 seconds

Wow, ok. This tells me what an amateur you are. You have never touched a real server. Go play with your workstation in your basement.

> i doubt that for glibc and openssl in recent versions

Yep, that's what I thought. It's not my fault that your abilities are lacking.
You do know that TLS 1.3 requires openssl 1.1.1, right?

I knew it was a mistake even to entertain replying to you. It won't happen again. You are probably this annoying person who was banned a few times from the mailing list or some other troll who thinks they are smart.
Either way, what gives you the right to spam this bug report without contributing any useful information? Don't answer. Just go away.

I'm done with you. I really have better things to do than wasting my time with the likes of you.
 [2021-05-06 07:50 UTC] nikic@php.net 
Moderation note: Comments from Reindl Harald have been removed, so the discussion might read a bit disjointed now.
 [2021-08-16 13:14 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2021-08-16 13:14 UTC] cmb@php.net 
> But apparently that's not enough for the devs to look into it.

There are more than 3000 other unresolved issues, so time is a bit
limited. :)

Anyhow, did you make any progress here?
 [2021-08-16 14:00 UTC] tessus@php.net 
Unfortunately I'm still pulling my hair out to find a zlib version 1.1.3 anywhere on my server.
There isn't one,
So for more than 4 months I haven't been able to use PHP 7.4 anymore, because many web apps rely on gz functions.
 [2021-08-16 14:13 UTC] cmb@php.net 
Which SAPI do you use?  If it's apache2handler, I can imagine that
this zlib is already there.  Or does the issue also happen running
PHP CLI scripts?
 [2021-08-16 14:59 UTC] tessus@php.net 
Nope, apache2handler is basically obsolete. It can't be used for event mpm, nor does h2 work.

I'm using php-fpm.

Yes, it also happens with the cli.
 [2021-08-16 15:06 UTC] cmb@php.net
-Status: Feedback +Status: Open -Assigned To: cmb +Assigned To:
 [2021-08-16 15:06 UTC] cmb@php.net 
Then I'm at a loss, again.  Sorry.
 [2021-08-16 15:10 UTC] tessus@php.net 
Yep, same here. I'm totally puzzled by all this. 

Especially because 7.3 does not find and link against a mystical 1.1.3 version that does not exist on my system.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Mon Nov 03 05:00:01 2025 UTC