I have now confirmed that this bug also exists in PHP version 5.3.0RC1 on CentOs 5.1.

I tried closing and freeing the imap connection every 100 calls to imap_body() to see if it was the resource that was holding on to the memory.  This did not help.

Code:
if ($i % 100 === 0) {
    echo "Releasing mailbox\n";
    imap_close($mailbox);
    $mailbox = null;
    unset($mailbox);
    $mailbox = @imap_open($connect_string, $username, $password, 0, 3);
    $reopen_success = imap_reopen($mailbox, $connect_string, 0, 3);
}

A co-worker and I have created a diff that seems to fix this issue.  Would someone else mind checking it out and seeing if there are any problems with it?

diff php_imap.c php_imap_fixed.c 
1251a1252
>   char *body = mail_fetchtext_full (imap_le_struct->imap_stream, Z_LVAL_PP(msgno), NIL, myargc==3 ? Z_LVAL_PP(pflags) : NIL);
1253c1254,1255
<   RETVAL_STRING(mail_fetchtext_full (imap_le_struct->imap_stream, Z_LVAL_PP(msgno), NIL, myargc==3 ? Z_LVAL_PP(pflags) : NIL), 1);
---
>     RETVAL_STRING(body, 1);
>     free(body);

Can you provide the patch as a unified diff, just use the -u flag to cvs diff.

Here's a unified diff:
diff -u php-5.2.9/ext/imap/php_imap.c php-5.2.9-fixed/ext/imap/php_imap.c
--- php-5.2.9/ext/imap/php_imap.c        2008-12-31 06:17:38.000000000 -0500
+++ php-5.2.9-fixed/ext/imap/php_imap.c        2009-04-23 13:56:26.000000000 -0400
@@ -1250,7 +1250,10 @@
                RETURN_FALSE;
        }

-        RETVAL_STRING(mail_fetchtext_full (imap_le_struct->imap_stream, Z_LVAL_PP(msgno), NIL, myargc==3 ? Z_LVAL_PP(pflags) : NIL), 1);
+        char *body = mail_fetchtext_full (imap_le_struct->imap_stream, Z_LVAL_PP(msgno), NIL, myargc==3 ? Z_LVAL_PP(pflags) : NIL);
+
+        RETVAL_STRING(body, 1);
+        free(body);
}
/* }}} */

Slightly modified version committed in all branches. Thanks for your work!

Hey guys it looks like we were a little hasty in submitting this patch.  It now seems that our patch does lessen the memory leak, but does not eradicate it.  We ran our test script using the patch and it seemed to work, but running the actual migration program shows that there is still a leak.  Before our program would migrate ~1.5gb of mail now it migrates ~2.4gb before running out of memory.  We have updated our test script to better expose the memory leak:

/**
 * To watch memory usage use:
 * ps -eo pid,ppid,rss,vsize,pcpu,pmem,cmd -ww --sort=pid | grep "\(memory-usage-test\)\|\(PID\)" | grep -v grep
 */
$flags = '/novalidate-cert';
$host = 'a.host.com:143';
$username = '[email protected]';
$password = 'password';
$folder = 'INBOX';

$base_imap_string = '{' . $host . $flags . '}';
$connect_string = $base_imap_string . $folder;

$mailbox = @imap_open($connect_string, $username, $password, 0, 3);
$reopen_success = imap_reopen($mailbox, $connect_string, 0, 3);

$message_ids = imap_search($mailbox, "ALL", SE_UID);
$num_msgs = count($message_ids);
for ($i = 0; $i < 1000000; $i++) {
    $msg_num = $i % $num_msgs;
    imap_body($mailbox, $message_ids[$msg_num], FT_UID);
}

Will test it using my test imap server. The last fix is correct but there is certainly other sources of leaks.

After a little more testing we opened and closed the imap connection after every 50 messages.  This seems to release the memory and works as a temporary fix.


Also, we have confirmed the same bug in imap_fetchbody.  I tested applying the same fix as above and it seems to fix the issue.

There are also similar bugs with the criteria and other various imap structure which should be freed as well. fix for the criteria on its way.

2nd review of cclient, it is wrong to free the body as it is a simple pointer to the msg data, not a copy of its contents. However the criteria has to be freed. I'd to revert the fix for fetch_body and looks for better solution (maybe userland) to minimize the memory usage.

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.