From: ktk at bigfoot dot com
Operating system: Slackware GNU/Linux
PHP version: 5.2.1
PHP Bug Type: LDAP related
Bug description: Memory leak found in ldap_{first|next}_attribute
Description:
------------
PHP "leaks" memory in the ldap_{first|next}_attribute() functions.
Interestingly, the ldap_get_attributes() function does not leak.
I put "leaks" in quotes because the leak() function does not detect the
issue; presumably, the memory is programmatically freed, just not until PHP
exits.
If one does something like:
while (true) {
$s = ldap_search($link, $base, $filter, $atts);
for ($e = ldap_first_entry($link, $s); $e != false;
$e = ldap_next_entry($link, $e)) {
for ($a = ldap_first_attribute($link, $e, $ber); $a;
$a = ldap_next_attribute($link, $e, $ber)) { }
}
ldap_free_result($s);
}
then PHP will eat all available memory and bomb with a memory allocation
error. Unbinding and re-binding has no effect.
Reproduce code:
---------------
A working 51-line script that shows memory allocation versus iteration
count can be found at this url:
http://enterprise.bidmc.harvard.edu/private/php-bugs/ldap-leak-test.php
There are a few variables you can set/tweak at the top to get it to point
at whatever LDAP server you have handy. Choosing a search filter that
returns a dozen or so entries is ideal for showing the runaway memory. You
can also change the "$fail" variable from True to False, which will stop
the leak by way of using the roughly-equivalent function
ldap_get_attributes().
Expected result:
----------------
PHP's memory subsystem should collect and re-use the freed memory. After
some number of iterations of the test script (typically 100 to 500) the
results reported by memory_get_usage() should remain stable.
Actual result:
--------------
The results reported by memory_get_usage() increase fairly linearly with
each iteration until memory_limit is reached, whence the script bombs.
--
Edit bug report at http://bugs.php.net/?id=41127&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41127&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41127&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41127&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41127&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41127&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41127&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=41127&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=41127&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41127&r=support
Expected behavior: http://bugs.php.net/fix.php?id=41127&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41127&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41127&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41127&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41127&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41127&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=41127&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41127&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41127&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41127&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=41127&r=mysqlcfg
