php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #35646 %{mod_php_memory_usage}n is not reset after exit (works in PHP 5)
Submitted: 2005-12-12 14:51 UTC Modified: 2005-12-13 19:53 UTC
From: vovik at getart dot ru Assigned:
Status: Closed Package: Apache2 related
PHP Version: 4CVS-2005-12-13 (snap) OS: RHEL 4
Private report: No CVE-ID: None
 [2005-12-12 14:51 UTC] vovik at getart dot ru
Description:
------------
I using 'LogFormat "%h %l %u %t \"%r\" %>s %b php(%{mod_php_memory_usage}n)" common' in httpd.conf for logging php memory usage.

If php script exited on fatal error due to memory limitation, %{mod_php_memory_usage}n keeps high value for all following requests to this apache child.

Reproduce code:
---------------
if (@$_GET["test"] == 1) {
    print "Allocated: ".memory_get_usage();

} else {
    ini_set("memory_limit", 1048576 * 100); // 100K

    // PHP exited in file_get_contents with message:
    // PHP Fatal error:  Allowed memory size of 104857600 bytes exhausted
    $bigfile = file_get_contents("/etc/termcap"); // this file is about 800K on my host
}

First, run this script without parameter, next with ?test=1. Check apache log then.

Expected result:
----------------
[12/Dec/2005:13:28:47 +0000] "GET /test.php HTTP/1.1" 200 - php(806944)
[12/Dec/2005:13:28:57 +0000] "GET /test.php?test=1 HTTP/1.1" 200 16 php(*****) // not the same as previous, should be much lower

Actual result:
--------------
[12/Dec/2005:13:28:47 +0000] "GET /test.php HTTP/1.1" 200 - php(806944)
[12/Dec/2005:13:28:57 +0000] "GET /test.php?test=1 HTTP/1.1" 200 16 php(806944)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-12-12 18:28 UTC] sniper@php.net
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

Memory isn't _really_ freed but during shutdown.
 [2005-12-13 09:05 UTC] vovik at getart dot ru
I'll try to explain the issue more clear.

If one php script (heavy.php) tried to allocate memory more than memory_limit php.ini setting it will exited with fatal error ("Allowed memory size exhausted"). In apache access_log it reports highest memory value used (close to php memory_limit).

Another script (light.php), which allocate small amount of memory, executed after. And it will report in access_log the same high value as heavy.php. Obviously, it happens only if light.php executed on the same apache child.
If i try to call memory_get_usage() in light.php - it reports normal low value. But in access_log it still the same as heavy.php. All following requests to this apache child reports one value for memory peak in access_log.

As result, access_log looks like this:
"GET /heavy.php HTTP/1.1" 200 - php(806944)
"GET /light.php HTTP/1.1" 200 16 php(806944)
"GET /something.php HTTP/1.1" 200 160 php(806944)
... and so on ... 

It looks like php keeps allocated memory peak and not drops it after fatal error due to memory limitation.
 [2005-12-13 14:45 UTC] vovik at getart dot ru
I've tried latest php4 snapshot (php4-STABLE-200512131136) and got the same result. But in php5 this issue is solved.

I've compared sources of php4 and php5. Solution looks very simple.

*** php4-STABLE-200512131136/Zend/zend_alloc.c.orig     2005-12-13 12:56:25.375626097 +0000
--- php4-STABLE-200512131136/Zend/zend_alloc.c  2005-12-13 12:57:23.877054536 +0000
***************
*** 538,543 ****
--- 538,544 ----

  #if MEMORY_LIMIT
        AG(memory_exhausted)=0;
+       AG(allocated_memory_peak)=0;
  #endif
 [2005-12-13 19:53 UTC] tony2001@php.net
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/.
 
Thank you for the report, and for helping us make PHP better.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 12:01:29 2024 UTC