Edit report at https://bugs.php.net/bug.php?id=65775&edit=1
ID: 65775
Comment by: clyde dot adams at mailismagic dot com
Reported by: clyde dot adams at mailismagic dot com
Summary: Random memory leak between runs with identical data
inputs
Status: Feedback
Type: Bug
Package: *General Issues
Operating System: OSX Server 10.5.8
PHP Version: Irrelevant
Block user comment: N
Private report: N
New Comment:
According to phpinfo(): zend.enable_gc On
No opcode cache.
Apache/2.2.21 (Unix) PHP/5.3.27 mod_ssl/2.2.21 OpenSSL/1.0.0h
Apache is running PHP as a module.
Unfortunately, I can't upgrade the box to 5.4 (yet). Also, the test script I
made doesn't replicate the problem for me either - it merely represents a
working, pared back example of the data as it is headed into the foreach logic.
Previous Comments:
------------------------------------------------------------------------
[2013-09-27 20:02:41] [email protected]
Well, since we no longer support PHP 5.3.x you could at least try to replicate
in PHP 5.4/5.5 and let us know if you are still able to.
I did a quick test using your provided script and couldn't see any issue.
Also, since I suspect you are only able to see this when running under a web
server and not from CLI, you should indicate how you are running PHP, whether
enable_gc is on or off and whether and which opcode you are using. All of which
could affect this.
------------------------------------------------------------------------
[2013-09-27 18:35:28] clyde dot adams at mailismagic dot com
Description:
------------
While we are running PHP 5.3.27 here, I see nothing in the changelog for newer
versions of PHP that indicates this bug is even possibly fixed. The code on
pastebin is a simplification of the scenario. In my real-world environment, a
query on a database is run, results are built up in an array in PHP, and then
boiled down into a second array. Everything is fine until the inner foreach()
loop. At that point, all bets are off as to whether or not PHP will run itself
out of memory. The exact same inputs resulting in the exact same data in
$rows2 will sometimes cause PHP to suddenly chew up 128MB RAM and terminate the
script - interestingly, not passing 'true' to memory_get_usage() says only 40MB
is being used at the time PHP terminates the script while claiming 128MB RAM is
being used. The problem seems to hinge on this line:
$row[1] = htmlspecialchars(implode(", ", $idmap[$row[1]]));
If I break it out so the variable being assigned doesn't reference itself in
the same statement:
$id = $idmap[$row[1]];
$row[1] = htmlspecialchars(implode(", ", $id));
The problem goes away as well. There is nothing involved in the foreach
statements beyond basic PHP arrays, numbers, and strings (i.e. no objects).
The amount of memory used before the foreach() lines is normal (about 10MB).
When the foreach statements complete successfully, the amount of memory used is
still normal (about 20MB). So there isn't always a runaway memory leak.
Attempting to replicate this issue will likely cause headaches. When I added
the commented out if-statement so I could output debugging information without
affecting other users, the problem went away...even though the if-statement
technically does absolutely nothing. This made pinpointing the problem a lot
more difficult in userland PHP.
There is indeed a bug here. I wouldn't be filing a bug report or writing a
test script if I wasn't certain about the issue.
Test script:
---------------
http://pastebin.com/z1KBmJLN
Expected result:
----------------
Consistent memory usage between runs with identical data. If statements that
do nothing should not have an effect on memory usage.
Actual result:
--------------
PHP inexplicably consumes all memory up to the limit in the INI file. But only
sometimes. For the exact same inputs and data.
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=65775&edit=1
