#49445 [NEW]: Segfault on connection close
From: jake dot levitt at mailtrust dot com
Operating system: CentOS 5
PHP version: 5.3.0
PHP Bug Type: IMAP related
Bug description: Segfault on connection close
Description:
If an IMAP server closes a connection without sending a BYE command, PHP
segfaults on the next IMAP command run on the mailbox resource. I noticed
this while testing against an exchange server, where I was selecting a
folder that doesn't exist. After 10 times it disconnected me without
sending a BYE command. When this happens PHP segfaulted, which doesn't
allow for the script to do any error handling.
Reproduce code:
---
?php
//Try testing against an exchange server that disconnects after a
//certain number of bad commands
$flags = '/novalidate-cert';
$host = 'secure.emailsrvr.com:143';
$username = 'notewort...@sts.com';
$password = 'webmail';
$base_imap_string = '{' . $host . $flags . '}';
$connect_string = $base_imap_string . 'INBOX';
$mailbox = imap_open($connect_string, $username, $password, 0, 3);
$connect_string = $base_imap_string . 'Does not exist';
for ($i = 0; $i 10; $i++) {
$reopen_success = imap_reopen($mailbox, $connect_string, 0, 3);
}
Expected result:
imap_reopen either returns false or throws a PHP error.
Actual result:
--
The script segfaults.
--
Edit bug report at http://bugs.php.net/?id=49445edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49445r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49445r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49445r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49445r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49445r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49445r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49445r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49445r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49445r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49445r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49445r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49445r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49445r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49445r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49445r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49445r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49445r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49445r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49445r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49445r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49445r=mysqlcfg
#49425 [NEW]: imap_reopen() returns TRUE instead FALSE called with nonexistant mailbox
From: jake dot levitt at mailtrust dot com
Operating system: CentOS 5
PHP version: 5.3.0
PHP Bug Type: IMAP related
Bug description: imap_reopen() returns TRUE instead FALSE called with
nonexistant mailbox
Description:
When calling imap_reopen() on a folder that doesn't exist, the function
returns true instead of the expected result of false. It seems this was
reported back in 2002 but marked as bogus
(http://bugs.php.net/bug.php?id=15197). I have reproduced this bug in the
most recent version of php.
Reproduce code:
---
?php
$flags = '/novalidate-cert';
$host = 'imap.server.example.com:143';
$username = 'test.u...@example.com';
$password = 'password';
$folder = 'INBOX';
$base_imap_string = '{' . $host . $flags . '}';
$connect_string = $base_imap_string . $folder;
$mailbox = imap_open($connect_string, $username, $password, 0, 3);
$connect_string = $base_imap_string . $folder . '.No such critter';
$reopen_success = imap_reopen($mailbox, $connect_string, 0, 3);
$error_message = imap_last_error();
if (!$mailbox) {
exit(0);
}
if ($reopen_success) {
echo Reopen SUCCEEDED and error message is: $error_message\n;
} else {
echo Reopen FAILED and error message is: $error_message\n;
}
Expected result:
Output:
Reopen FAILED and error message is: Mailbox doesn't exist: No such critter
Actual result:
--
Output:
Reopen SUCCEEDED and error message is: Mailbox doesn't exist: No such
critter
--
Edit bug report at http://bugs.php.net/?id=49425edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49425r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49425r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49425r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49425r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49425r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49425r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49425r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49425r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49425r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49425r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49425r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49425r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49425r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49425r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49425r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49425r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49425r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49425r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49425r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49425r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49425r=mysqlcfg
#47940 [Csd-Opn]: imap_body() leaks memory
ID: 47940
User updated by: jake dot levitt at mailtrust dot com
Reported By: jake dot levitt at mailtrust dot com
-Status: Closed
+Status: Open
Bug Type: IMAP related
Operating System: Ubuntu 8.04 (linux:2.6.24-21)
PHP Version: 5.2.9
New Comment:
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 = 'a.u...@a.host.com';
$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 100; $i++) {
$msg_num = $i % $num_msgs;
imap_body($mailbox, $message_ids[$msg_num], FT_UID);
}
Previous Comments:
[2009-04-23 22:35:57] paj...@php.net
Slightly modified version committed in all branches. Thanks for your
work!
[2009-04-23 21:37:27] jake dot levitt at mailtrust dot com
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.c2008-12-31 06:17:38.0
-0500
+++ php-5.2.9-fixed/ext/imap/php_imap.c2009-04-23
13:56:26.0 -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);
}
/* }}} */
[2009-04-23 21:03:39] scott...@php.net
Can you provide the patch as a unified diff, just use the -u flag to
cvs diff.
[2009-04-23 19:05:24] jake dot levitt at mailtrust dot com
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);
[2009-04-14 18:41:36] jake dot levitt at mailtrust dot com
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);
}
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/47940
--
Edit this bug report at http://bugs.php.net/?id=47940edit=1
#47940 [Opn]: imap_body() leaks memory
ID: 47940
User updated by: jake dot levitt at mailtrust dot com
Reported By: jake dot levitt at mailtrust dot com
Status: Open
Bug Type: IMAP related
Operating System: Ubuntu 8.04 (linux:2.6.24-21)
PHP Version: 5.2.9
New Comment:
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);
Previous Comments:
[2009-04-14 18:41:36] jake dot levitt at mailtrust dot com
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);
}
[2009-04-14 15:43:56] jake dot levitt at mailtrust dot com
I have now confirmed that this bug also exists in PHP version 5.3.0RC1
on CentOs 5.1.
[2009-04-09 22:31:04] jake dot levitt at mailtrust dot com
Description:
I am creating a script that migrates e-mail from one server to another.
On really large mailboxes, my script dies with PHP Fatal error: Out
of memory (allocated 13631488) (tried to allocate 3381512 bytes) even
though memory_get_usage() function was reporting that the script was
only using around 10 MBs. My memory_limit is set to 1GB (but this isn't
coming into play). When I examined the memory usage of the script using
ps, I noticed that it would gradually increase until it reached ~92% of
system memory (I have 2GB). I eventually found that when I commented
out imap_body, the memory usage would stay flat. I wrote a script that
can reproduce this bug. I run the script in the background and then
watch its memory using: ps -eo pid,ppid,rss,vsize,pcpu,pmem,cmd -ww
--sort=pid | grep \(memory-usage\)\|\(PID\) | grep -v grep. Please
let me know if you need additional information. This script is intended
to be run on the cli.
Reproduce code:
---
?php
$flags = '/novalidate-cert';
$host = 'mail.server.com:143';
$username = 'user';
$password = 'pass';
$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);
for ($i = 0; $i 1000; $i++) {
imap_body($mailbox, $message_ids[0], FT_UID | FT_PEEK);
}
Expected result:
I would expect that memory usage as viewed by the ps command stays
relatively flat.
Actual result:
--
Memory usage as viewed by the ps command increases over time until the
script eventually dies with an out of memory error given.
--
Edit this bug report at http://bugs.php.net/?id=47940edit=1
#47940 [Opn]: imap_body() leaks memory
ID: 47940
User updated by: jake dot levitt at mailtrust dot com
Reported By: jake dot levitt at mailtrust dot com
Status: Open
Bug Type: IMAP related
Operating System: Ubuntu 8.04 (linux:2.6.24-21)
PHP Version: 5.2.9
New Comment:
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.c2008-12-31 06:17:38.0
-0500
+++ php-5.2.9-fixed/ext/imap/php_imap.c2009-04-23
13:56:26.0 -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);
}
/* }}} */
Previous Comments:
[2009-04-23 21:03:39] scott...@php.net
Can you provide the patch as a unified diff, just use the -u flag to
cvs diff.
[2009-04-23 19:05:24] jake dot levitt at mailtrust dot com
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);
[2009-04-14 18:41:36] jake dot levitt at mailtrust dot com
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);
}
[2009-04-14 15:43:56] jake dot levitt at mailtrust dot com
I have now confirmed that this bug also exists in PHP version 5.3.0RC1
on CentOs 5.1.
[2009-04-09 22:31:04] jake dot levitt at mailtrust dot com
Description:
I am creating a script that migrates e-mail from one server to another.
On really large mailboxes, my script dies with PHP Fatal error: Out
of memory (allocated 13631488) (tried to allocate 3381512 bytes) even
though memory_get_usage() function was reporting that the script was
only using around 10 MBs. My memory_limit is set to 1GB (but this isn't
coming into play). When I examined the memory usage of the script using
ps, I noticed that it would gradually increase until it reached ~92% of
system memory (I have 2GB). I eventually found that when I commented
out imap_body, the memory usage would stay flat. I wrote a script that
can reproduce this bug. I run the script in the background and then
watch its memory using: ps -eo pid,ppid,rss,vsize,pcpu,pmem,cmd -ww
--sort=pid | grep \(memory-usage\)\|\(PID\) | grep -v grep. Please
let me know if you need additional information. This script is intended
to be run on the cli.
Reproduce code:
---
?php
$flags = '/novalidate-cert';
$host = 'mail.server.com:143';
$username = 'user';
$password = 'pass';
$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);
for ($i = 0; $i 1000; $i++) {
imap_body($mailbox, $message_ids[0], FT_UID | FT_PEEK);
}
Expected result:
I would expect that memory usage as viewed by the ps command stays
relatively flat.
Actual result:
--
Memory usage as viewed by the ps command increases over time until the
script eventually dies with an out of memory error given.
--
Edit this bug report at http://bugs.php.net/?id=47940edit=1
#47940 [Opn]: imap_body() leaks memory
ID: 47940
User updated by: jake dot levitt at mailtrust dot com
Reported By: jake dot levitt at mailtrust dot com
Status: Open
Bug Type: IMAP related
Operating System: Ubuntu 8.04 (linux:2.6.24-21)
PHP Version: 5.2.9
New Comment:
I have now confirmed that this bug also exists in PHP version 5.3.0RC1
on CentOs 5.1.
Previous Comments:
[2009-04-09 22:31:04] jake dot levitt at mailtrust dot com
Description:
I am creating a script that migrates e-mail from one server to another.
On really large mailboxes, my script dies with PHP Fatal error: Out
of memory (allocated 13631488) (tried to allocate 3381512 bytes) even
though memory_get_usage() function was reporting that the script was
only using around 10 MBs. My memory_limit is set to 1GB (but this isn't
coming into play). When I examined the memory usage of the script using
ps, I noticed that it would gradually increase until it reached ~92% of
system memory (I have 2GB). I eventually found that when I commented
out imap_body, the memory usage would stay flat. I wrote a script that
can reproduce this bug. I run the script in the background and then
watch its memory using: ps -eo pid,ppid,rss,vsize,pcpu,pmem,cmd -ww
--sort=pid | grep \(memory-usage\)\|\(PID\) | grep -v grep. Please
let me know if you need additional information. This script is intended
to be run on the cli.
Reproduce code:
---
?php
$flags = '/novalidate-cert';
$host = 'mail.server.com:143';
$username = 'user';
$password = 'pass';
$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);
for ($i = 0; $i 1000; $i++) {
imap_body($mailbox, $message_ids[0], FT_UID | FT_PEEK);
}
Expected result:
I would expect that memory usage as viewed by the ps command stays
relatively flat.
Actual result:
--
Memory usage as viewed by the ps command increases over time until the
script eventually dies with an out of memory error given.
--
Edit this bug report at http://bugs.php.net/?id=47940edit=1
#47940 [Opn]: imap_body() leaks memory
ID: 47940
User updated by: jake dot levitt at mailtrust dot com
Reported By: jake dot levitt at mailtrust dot com
Status: Open
Bug Type: IMAP related
Operating System: Ubuntu 8.04 (linux:2.6.24-21)
PHP Version: 5.2.9
New Comment:
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);
}
Previous Comments:
[2009-04-14 15:43:56] jake dot levitt at mailtrust dot com
I have now confirmed that this bug also exists in PHP version 5.3.0RC1
on CentOs 5.1.
[2009-04-09 22:31:04] jake dot levitt at mailtrust dot com
Description:
I am creating a script that migrates e-mail from one server to another.
On really large mailboxes, my script dies with PHP Fatal error: Out
of memory (allocated 13631488) (tried to allocate 3381512 bytes) even
though memory_get_usage() function was reporting that the script was
only using around 10 MBs. My memory_limit is set to 1GB (but this isn't
coming into play). When I examined the memory usage of the script using
ps, I noticed that it would gradually increase until it reached ~92% of
system memory (I have 2GB). I eventually found that when I commented
out imap_body, the memory usage would stay flat. I wrote a script that
can reproduce this bug. I run the script in the background and then
watch its memory using: ps -eo pid,ppid,rss,vsize,pcpu,pmem,cmd -ww
--sort=pid | grep \(memory-usage\)\|\(PID\) | grep -v grep. Please
let me know if you need additional information. This script is intended
to be run on the cli.
Reproduce code:
---
?php
$flags = '/novalidate-cert';
$host = 'mail.server.com:143';
$username = 'user';
$password = 'pass';
$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);
for ($i = 0; $i 1000; $i++) {
imap_body($mailbox, $message_ids[0], FT_UID | FT_PEEK);
}
Expected result:
I would expect that memory usage as viewed by the ps command stays
relatively flat.
Actual result:
--
Memory usage as viewed by the ps command increases over time until the
script eventually dies with an out of memory error given.
--
Edit this bug report at http://bugs.php.net/?id=47940edit=1
#47940 [NEW]: imap_body causes memory leak
From: jake dot levitt at mailtrust dot com
Operating system: Ubuntu 8.04 (linux:2.6.24-21)
PHP version: 5.2.9
PHP Bug Type: Reproducible crash
Bug description: imap_body causes memory leak
Description:
I am creating a script that migrates e-mail from one server to another.
On really large mailboxes, my script dies with PHP Fatal error: Out of
memory (allocated 13631488) (tried to allocate 3381512 bytes) even though
memory_get_usage() function was reporting that the script was only using
around 10 MBs. My memory_limit is set to 1GB (but this isn't coming into
play). When I examined the memory usage of the script using ps, I noticed
that it would gradually increase until it reached ~92% of system memory (I
have 2GB). I eventually found that when I commented out imap_body, the
memory usage would stay flat. I wrote a script that can reproduce this
bug. I run the script in the background and then watch its memory using:
ps -eo pid,ppid,rss,vsize,pcpu,pmem,cmd -ww --sort=pid | grep
\(memory-usage\)\|\(PID\) | grep -v grep. Please let me know if you need
additional information. This script is intended to be run on the cli.
Reproduce code:
---
?php
$flags = '/novalidate-cert';
$host = 'mail.server.com:143';
$username = 'user';
$password = 'pass';
$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);
for ($i = 0; $i 1000; $i++) {
imap_body($mailbox, $message_ids[0], FT_UID | FT_PEEK);
}
Expected result:
I would expect that memory usage as viewed by the ps command stays
relatively flat.
Actual result:
--
Memory usage as viewed by the ps command increases over time until the
script eventually dies with an out of memory error given.
--
Edit bug report at http://bugs.php.net/?id=47940edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47940r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47940r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47940r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47940r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47940r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47940r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47940r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47940r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47940r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47940r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47940r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47940r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47940r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47940r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47940r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47940r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47940r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47940r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47940r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47940r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47940r=mysqlcfg
