#41127 [NEW]: Memory leak found in ldap_{first|next}_attribute

From: Date: Tue, 17 Apr 2007 22:26:31 +0000
Subject: #41127 [NEW]: Memory leak found in ldap_{first|next}_attribute
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-111622@lists.php.net to get a copy of this message
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

« previous php.bugs (#111622) next »