php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #5571 memory leaks/huge reported virtual size
Submitted: 2000-07-14 03:21 UTC Modified: 2000-11-02 21:48 UTC
From: mookid at sigent dot ru Assigned:
Status: Closed Package: *General Issues
PHP Version: 4.0.3pl1 OS: Linux Mandrake 7.0+
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: mookid at sigent dot ru
New email:
PHP Version: OS:

 

 [2000-07-14 03:21 UTC] mookid at sigent dot ru
When I run Apache under root with dynamically linked PHP 4.0.1pl2, 'ps' reports huge VSZ values for httpd, about 70M. 'top' says the size is normal though. May this be a normal behaviour, related to MM, or what? When I ran it under a nonprivileged user, the size was okay.
Another thing is that httpd processes grow at each restart,
grabbing dozens of kilobytes in RSS and another 30 crazy megs in VSZ.

I built PHP against Apache 1.3.12 with the Russian patch,
EAPI and SSI patches applied.

Here's my configuration line:
./configure  --with-apxs=/usr/sbin/apxs --without-mysql --without-gd --disable-static --disable-debug --enable-pic --enable-inline-optimization --enable-versioning --prefix=/usr --with-config-file-path=/etc/httpd/conf --enable-magic-quotes --enable-debugger --enable-track-vars --enable-safe-mode --enable-discard-path --enable-force-cgi-redirect --enable-memory-limit --enable-trans-sid --with-exec-dir=/usr/bin --with-mod_charset --with-mm --with-regex=system --with-gdbm --enable-xml --enable-wddx --enable-sysvsem --enable-sysvshm

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-07-15 04:37 UTC] mookid at sigent dot ru
--without-mm configure option has eliminated huge memory size reports.
But memory leaks are still there.
 [2000-07-24 09:33 UTC] stas@php.net
Please compile PHP in debug mode - it will report possible leaks. Though, it might be as well leaks not in PHP - you seem to have real lot of stuff there. Try to eliminated apache modules and extensions one-by-one and see what happens - who is the leak source.
 [2000-07-30 14:37 UTC] zak@php.net
Changing status to feedback
 [2000-08-03 03:47 UTC] mookid at sigent dot ru
It doesn't help. I've removed all patches and modules from Apache and all extensions (but gdbm) from PHP, and it still grows on restarts. This is also observed on another box with Slackware.

PHP is built '--with-debug' doesn't report any violations.

 [2000-08-23 09:40 UTC] sniper@php.net
Exactly what do you mean with 'restarts' ??
Do you restart apache with:

apachectl stop
apachectl start 

??

Or 

apachectl restart 

??

--Jani


 [2000-09-02 19:43 UTC] mookid at sigent dot ru
Of course, I mean 'apachectl restart'.

 [2000-09-02 22:26 UTC] sniper@php.net
Upgrade to php4.0.2.  And try doing stop and start instead of restart.

--Jani
 [2000-10-02 22:30 UTC] sniper@php.net
No feedback. Reopen this bug report if problem still exists.

--Jani
 [2000-10-18 13:28 UTC] mookid at sigent dot ru
Yupee! I've spent some time at the debugger,
and here it is: the leak is in the configuration-scanner.
There plainly was no buffer deallocation in the scanner code, and the Apache module re-reading php.ini get a leak
by allocating the buffer again.

Here's the patch, that simple:

--- main/configuration-scanner.l	Mon Jun 26 22:15:49 2000
+++ main/configuration-scanner.l.new	Wed Oct 18 17:57:28 2000
@@ -180,3 +180,8 @@
 	php_error(E_NOTICE,"Unexpected character on line %d:  '%s' (ASCII %d)\n",yylineno,yytext,yytext[0]);
 #endif
 }
+
+<<EOF>> {
+	yy_delete_buffer(YY_CURRENT_BUFFER);
+	yyterminate();
+}

 [2000-11-02 21:48 UTC] zeev@php.net
Applied the patch as suggested.  Thanks!
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 25 09:01:29 2024 UTC