Description: ------------ with php version : 5.0.5, 4.4.2, 4.3.10, 4.3.3, 4.2.3 , they are no problem, but with 5.1.1 and 5.1.2 they are un memory leak... Test script: --------------- <?php require_once('PEAR.php'); set_time_limit(0); for($i = 0; $i < 500000; $i++) { $ret = PEAR::raiseError('error'); } ?> Expected result: ---------------- nothing Actual result: -------------- <br /> <b>Fatal error</b>: Allowed memory size of 8388608 bytes exhausted (tried to allocate 40 bytes) in <b>/usr/local/apache/pear/share/pear/PEAR.php</b> on line <b>857</b><br />

Sorry, but your problem does not imply a bug in PEAR itself. For a list of more appropriate places to ask for help using PEAR, please visit http://pear.php.net/support/ as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PEAR. PHP Memory leaks are php bugs, not pear.

this isn't even a memory leak, you have memory_limit enabled and set to 8M

Hm. Why this would be bogus bug. Is it just expected tor RaiseError to accocate more and more function in its calls. The limit of 8MB is not important here - you always can have longer loop and longer running programms. If Pear developers think it is OK to leak memory this way I would appreciate if there is information outwhere on how to run long running programms with PEAR so they do not leak. At this point I've been seen similar effects with different PEAR modules - it seems like it is common approach just no to care to free memory, assuming it is used for web page creation and so you can't leak too much anyway. Currently best approach for writing long running programms with PEAR seems to be forking and killing scripts after few objects were processed so leaks do not hurt you.

Follow what Toggg told you, you have to increase the memory limit in PHP.

but if I add unset like this <?php require_once('PEAR.php'); set_time_limit(0); for($i = 9; $i < 500000; $i++) { $ret = PEAR::raiseError('error'); unset($ret); } ?> PEAR (or php, I don't know) doesn't free $ret You do not think that it is a problem ?

"PEAR (or php, I don't know)" Voila, all memory operations (garbage collector included) are done by php, we (or you in your scripts) have no control on that. Check the php manual and google, there is good articles about this topic. There is no pear bug here.

I did not say anything, pierre :) It's obviously a php problem. I could reproduce it with a PHP 5.1.3-dev from last month and a fresh PHP 5.1.3RC2-dev. I isolated the origin of this "memory leak". It's the call to debug_backtrace() eating up the memory. If you add before the loop in your test script: $skip = &PEAR::getStaticProperty('PEAR_Error', 'skiptrace'); $skip = true; Then the problem disappears. This static just avoids the $this->backtrace = debug_backtrace(); in the PEAR_Error constructor. This little script crashes the same: <?php class test { var $backtrace = null; function test() { $this->backtrace = debug_backtrace(); } } set_time_limit(0); for($i = 0; $i <= 500000; $i++) { $ret = &new test(); unset($ret); } ?>

I pushed it there : http://bugs.php.net/?id=36847

http://bugs.php.net/?id=36847 finally comes back bogus , or at least "Documentation problem" I've put a work around there, for PEAR.php it would do: @@ -867,6 +867,7 @@ if (function_exists("debug_backtrace")) { if (!PEAR::getStaticProperty('PEAR_Error', 'skiptrace')) { $this->backtrace = debug_backtrace(); + unset($this->backtrace[0]['object']); } } if ($mode & PEAR_ERROR_CALLBACK) { <*sighs*>

and even, as we are in 4.3.0 and compat is client thing : @@ -864,10 +864,9 @@ $this->code = $code; $this->mode = $mode; $this->userinfo = $userinfo; - if (function_exists("debug_backtrace")) { - if (!PEAR::getStaticProperty('PEAR_Error', 'skiptrace')) { - $this->backtrace = debug_backtrace(); - } + if (!PEAR::getStaticProperty('PEAR_Error', 'skiptrace')) { + $this->backtrace = debug_backtrace(); + unset($this->backtrace[0]['object']); } if ($mode & PEAR_ERROR_CALLBACK) { $this->level = E_USER_NOTICE;

Is there a question about that ? This self back-reference was introduced by the 5.1.x debug_backtrace(). We don't need it in the PEAR_Error object , so better withdraw it direct from our side.

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.

This is actually still broken in 1.9.0 and still leaks memory very badly, this is highlighted by the PayPal SDK which makes significant use of code which detects raised errors and deals with them in natural code flow i.e. not really an error case. The quick solution is to call with the parameter true e.g. debug_backtrace( true ), which prevents the object reference being set.