PHP 4.0 Bug #9030 Updated: Serious memory leak with ob_gzhandler

ID: 9030 User Update by: del@doofer.org Status: Closed Bug Type: Zlib Related Description: Serious memory leak with ob_gzhandler Using the 2/01/01 snapshot, I can report that from my previous tests and currently running httpds, the leak appears fixed and ob_gzhandler is working very nicely compressing output. Thanks guys(girls?), (I for one voice of a grateful many) really appreciate the work that goes into developing PHP. Previous Comments: --------------------------------------------------------------------------- [2001-02-01 20:02:18] sniper@php.net This should be fixed in CVS now. Please try the latest CVS snapshot from http://snaps.php.net/ and reopen this bug report if problem still exists when using it. --Jani --------------------------------------------------------------------------- [2001-01-31 08:44:39] del@doofer.org I have noticed a that a serious memory leak is occuring with PHP when using the ob_gzhandler. It is noticable very quickly after starting Apache and reloading a few pages, the process size goes up dramatically - much more than if PHP is configured NOT to use the ob_gzhandler, which is I think when the Zend optimizer caches pages. Merely having support compiled in does not cause the effect. I have mod_ssl configured with: --with-layout=Del --with-apache=../apache --with-ssl=../openssl --with-mm=../mm --activate-module=src/modules/php4/libphp4.a --activate-module=src/modules/extra/mod_gzip.c PHP compiled with: --with-apache=../apache --enable-trans-sid --with-my-sql --with-zlib --with-mcrypt And then Apache is made with those options that mod_ssl configures it with. Using Zend optimizer 1.0.0 for PHP4.0.4. Despite the numerous different modules that are compiled into Apache, I feel it is with the ob_gzhandler that the problem lies as deactivating it seems to make the problem go away. --------------------------------------------------------------------------- Full Bug description available at: http://bugs.php.net/?id=9030