Re: DB getAll method has memory leaks

what i did for me, i simply resetted num_rows in the freeResult-method, but i didnt commit it or anything, since i have no idea of the DB/mysql.php and thought it might be better to tell it to the list, as i did (too) and for the pushErrorrHandling, i think it is ok to simply pop twice ... but a confirmation and bugfix from one of the PEAR.php-gurus would be great! i also reported both a while ago http://bugs.php.net/bug.php?id=19269&edit=2 http://marc.theaimsgroup.com/?l=pear-dev&m=103106909724414&w=2 thanks wolfram Jason Rust wrote:

Hello, Lately I've been using the DB class (specifically the mysql extension) to do large amounts of queries (i.e. 30,000+ in a single script). I have since noticed and been able to track down some bugs which make the getAll method (at least for mysql) get slower progressively (about 2 seconds every 1,000 queries on my machine) and eventually error out because memory runs out. The problems with getAll are twofold: 1. In common.php in the getAll method there is a while loop that fills the result table. Before that while loop $this->pushErrorHandling(PEAR_ERROR_RETURN); is called, and then afterwards $this->popErrorHandling(); is called. The only problem is that in pushErrorHangling two things are pushed onto the stack, the default error mode and the passed in error mode (at least in 0.91-dev), but in popErrorHandling array_pop is only used once. This means that for each getAll call the $_PEAR_error_handler_stack gets one element larger, so after 10,000 getAll calls in a script it becomes too big and the script fails because the maximum memory limit is exceeded. 2. In mysql.php in the simpleQuery method (which getAll uses) there is this bit of code: if (is_resource($result)) {

    $numrows = $this->numrows($result);
    if (is_object($numrows)) {
        return $numrows;
    }
    $this->num_rows[$result] = $numrows;

This num_rows variable is never used as far as I can tell, so I'm not sure why it's there. But either way, the problem is that for each query the $result variable increments so again after 10,000 getAll calls the num_rows variable is a huge array which causes the script to fail because of memory. So, these things would explain why getAll becomes progressively slower. I'm not sure if these are known bugs but I couldn't find anything about them either in the mailing lists or CVS so I thought I would let you all know. -Jason

-- Wolfram ... translating template system ... http://sourceforge.net/projects/simpletpl ... authentication system .... http://sf.net/projects/auth