#26847 [NEW]: memory leak with to_r and subject_r in mail() function
| From: | nutbar at innocent dot com | Date: | Thu, 08 Jan 2004 18:22:56 +0000 |
| Subject: | #26847 [NEW]: memory leak with to_r and subject_r in mail() function | ||
| Groups: | php.bugs | ||
| Request: | Send a blank email to php-bugs+get-52995@lists.php.net to get a copy of this message | ||
From: nutbar at innocent dot com
Operating system: any - source code issue
PHP version: 4.3.4
PHP Bug Type: Mail related
Bug description: memory leak with to_r and subject_r in mail() function
Description:
------------
In the actual source code for the PHP mail() function
(ext/standard/mail.c), it sets some variables up to hold the To: and
Subject: headers up, and other stuff.
The problem is that if you look at the initial code that checks if the
"to_len" count is greater than 0, it duplicates the "to" string to
"to_r"
and does some stuff to it.
It does the same sort of thing with subject_len, subject, and subject_r in
the exact same fashion.
After the new to_r and subject_r strings are used, it goes to free them,
but it does an if () test to see if it should or not - the if test
compares to_len and subject_len to see if they are greater than 0 and if
so, efree()'s them.
The problem is that in the code that does stuff with to_r and subject_r,
there are for loops which decrement to_len and subject_len so it can walk
the strings. By doing this, you bring the to_len and subject_len
variables to 0, thus nothing is ever efree()'d in the end, and you've got
a memory leak.
The leak is small and not noticable typically, but with mass mailing
scripts that loop using mail(), it could be huge.
Reproduce code:
---------------
See mail.c - lines 106 to 113, 129 to 136, and then 160 to 165.
Actual result:
--------------
I have not tested for an actual memory leak by calling mail() in a loop -
I was just going to write my own mail() function and was using the code in
mail.c to do it with, and came across this.
If this is a false report, I am sorry, but I do believe it's real.
--
Edit bug report at http://bugs.php.net/?id=26847&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26847&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26847&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26847&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26847&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26847&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26847&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26847&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=26847&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26847&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=26847&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=26847&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26847&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26847&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26847&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26847&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=26847&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26847&r=float