|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #47000 imap_body() and imap_savebody() memory leak.
Submitted: 2009-01-04 21:31 UTC Modified: 2009-04-30 20:27 UTC
From: alan at binarystars dot com Assigned: pajoye (profile)
Status: Not a bug Package: IMAP related
PHP Version: 5.2.8 OS: 2.6.25-14.fc9.i686
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
14 - 1 = ?
Subscribe to this entry?

 [2009-01-04 21:31 UTC] alan at binarystars dot com
# Problem:
imap_body() and imap_savebody() memory leak. During the following 
test of 26 email messages totaling a sum of 244.05Mb it seems you 
need TWICE the amount of memory in order to receive the message body 
via imap_body(). When using the imap_savebody() func it seems you 
need approximately the same amount of memory as the email message 
itself. The problem in particular is repeatable in any size email 
message... even when you unset the variables/objects returned by the 
func. In other words, you want to receive a message body of 5Mb using 
imap_body() func; you'll need 10Mb of available free RAM just to 
store the message body to a variable. Now, say you receive 10 
messages each at 5Mb, and unset all the variables. That would mean 
you'll need 100Mb of free memory to read all ten messages. See the 
reproduced code and the results for more information.

# Question:
Is there a way to flush the memory without actually exiting out of 
the script?

Reproduce code:
Colorized version: (30k)

Text version: (5.3k)

Result of method 1 via imap_body(): (3.6k)

Result of method 2 via imap_savebody():

Expected result:
When I run the script I expect it to use less (RSS) resident memory.

Actual result:
Instead of freeing up memory the script takes up more than Oracle 
running five hundred databases.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-01-05 16:01 UTC]
Can you run it via valgrind rather then php's memory checker? I suspect 
the issue is just some temp vars that will be cleaned up by garbage 
 [2009-01-05 17:17 UTC] alan at binarystars dot com
iliaa at, 
Give me a moment to update. Thanks.
 [2009-01-13 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2009-04-30 20:27 UTC]
Duplicate of #47940, which is now fixed in cvs (all active branches).
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Mar 02 09:01:29 2024 UTC