#45954 [Bgs]: memory leak with unset(array)
ID: 45954 User updated by: mail at milianw dot de Reported By: mail at milianw dot de Status: Bogus Bug Type: Performance problem Operating System: * PHP Version: 5.2.6 New Comment: Yes, thank you. Thats an explanation which clarifies things for me. Though one last thing: I was not speaking about a memory leak which persists after the process is finished, but one while the process is running. I was interested because while optimizing GeSHi I searched for ways to reduce the memory consumption / memory peaks and spotted this behaviour. You can close this bug. Thanks again. Previous Comments: [2008-09-02 08:44:04] [EMAIL PROTECTED] The internal memory manager is keeping tabs of the memory and will reuse it again if there is a memory allocation that it can fit in the block. You can use valgrind and see that the memory is in fact free'd when the request ends. [2008-09-01 17:48:18] mail at milianw dot de So there is simply no way at all to delete / free / unset variables in PHP? But why does it work perfectly (i.e. like I imagine it should) when I unset a string, even a very large one? That one frees the memory instantaneously. But not so for arrays. I simply cannot see the reasoning behind this. When a programmer calls unset he seems to know that this very variable can be freed, or not? So why do we need to wait for a GC to step in and do the actual cleanup? As far as my limited knowledge goes manual delete/free is compatible with a GC, or not? Or is it only possible to free simple strings, ints etc. but not arrays? Take this code: http://bugs.php.net/bug.php?id=41713 which tells a similar story, but it should be fixed as far as the bug report tells. Additionally it was Windows only yet I spotted the described behaviour first on a Linux machine. -- Edit this bug report at http://bugs.php.net/?id=45954&edit=1
#45954 [Bgs]: memory leak with unset(array)
ID: 45954 User updated by: mail at milianw dot de Reported By: mail at milianw dot de Status: Bogus Bug Type: Performance problem Operating System: * PHP Version: 5.2.6 New Comment: So there is simply no way at all to delete / free / unset variables in PHP? But why does it work perfectly (i.e. like I imagine it should) when I unset a string, even a very large one? That one frees the memory instantaneously. But not so for arrays. I simply cannot see the reasoning behind this. When a programmer calls unset he seems to know that this very variable can be freed, or not? So why do we need to wait for a GC to step in and do the actual cleanup? As far as my limited knowledge goes manual delete/free is compatible with a GC, or not? Or is it only possible to free simple strings, ints etc. but not arrays? Take this code: http://bugs.php.net/bug.php?id=41713 which tells a similar story, but it should be fixed as far as the bug report tells. Additionally it was Windows only yet I spotted the described behaviour first on a Linux machine. -- Edit this bug report at http://bugs.php.net/?id=45954&edit=1
#45954 [NEW]: memory leak with unset(array)
From: mail at milianw dot de Operating system: linux, windows PHP version: 5.2.6 PHP Bug Type: Performance problem Bug description: memory leak with unset(array) Description: When you setup an array and unset() it afterwards, not all memory is freed. I've run the code below on various PHP versions, including 5.2.6 (via Xampp) on Linux and Windows and always get output like: startup:64296 array setup:13789672 unsetted array: 129284 The end value is more than twice as large as the start value. Also interestingly is that low values in the for loop [e.g. for($i = 0; $i < 1; ++$i)] result in outputs like startup: 64296 array setup:64864 unsetted array: 64864 Could it be that unset() relies on the Garbage Collector to do the work instead of really destroying the variables? But then I find it strange that even if I put a sleep(10) after the unset I still get the same outputs for "unsetted array". Reproduce code: --- http://bugs.php.net/bug.php?id=41713 which tells a similar story, but it should be fixed as far as the bug report tells. Additionally it was Windows only yet I spotted the described behaviour first on a Linux machine. -- Edit bug report at http://bugs.php.net/?id=45954&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45954&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45954&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45954&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45954&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45954&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45954&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45954&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45954&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45954&r=support Expected behavior:http://bugs.php.net/fix.php?id=45954&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45954&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45954&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45954&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45954&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45954&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45954&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45954&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45954&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45954&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45954&r=mysqlcfg
