Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:64997 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 88381 invoked from network); 16 Jan 2013 20:00:06 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Jan 2013 20:00:06 -0000 Received: from [127.0.0.1] ([127.0.0.1:6581]) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ECSTREAM id 35/91-14541-6C607F05 for ; Wed, 16 Jan 2013 15:00:06 -0500 X-Host-Fingerprint: 87.102.188.133 cable-static-188-133.intergga.ch Received: from [87.102.188.133] ([87.102.188.133:14559] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AE/81-14541-05507F05 for ; Wed, 16 Jan 2013 14:53:53 -0500 Message-ID: To: internals@lists.php.net Date: Wed, 16 Jan 2013 20:53:51 +0100 User-Agent: Postbox 3.0.6 (Windows/20121031) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 87.102.188.133 Subject: Memory leak after calling exit() when Zend MM is turned off? From: dev@snapserv.net (Pascal Mathis) Hi internals! I am currently developing a Zend extension. Because the Zend MM leak reports are not really useful sometimes, I switched the memory manager off with the environment variable USE_ZEND_ALLOC=0, so that I can use valgrind. Right now I have found some kind of memory leak. You can use every script which has an exit()-call to reproduce this leak. For example: If you run this PHP script with valgrind, it will report some ugly memory leak: valgrind version: valgrind-3.6.0.SVN-Debian PHP Version: 5.4.10 (debug) Configure options: --disable-all --disable-cgi --enable-debug --- Command: export USE_ZEND_ALLOC=0 && valgrind --leak-check=full php-5.4.10-debug test.php --- Report: ==5693== HEAP SUMMARY: ==5693== in use at exit: 420 bytes in 4 blocks ==5693== total heap usage: 8,355 allocs, 8,351 frees, 2,503,705 bytes allocated ==5693== ==5693== 420 (240 direct, 180 indirect) bytes in 1 blocks are definitely lost in loss record 4 of ==5693== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==5693== by 0x5E08C4: _emalloc (zend_alloc.c:2423) ==5693== by 0x5C11C3: compile_file (zend_language_scanner.l:551) ==5693== by 0x617311: zend_execute_scripts (zend.c:1301) ==5693== by 0x58A22F: php_execute_script (main.c:2482) ==5693== by 0x768967: do_cli (php_cli.c:988) ==5693== by 0x76987C: main (php_cli.c:1364) ==5693== ==5693== LEAK SUMMARY: ==5693== definitely lost: 240 bytes in 1 blocks ==5693== indirectly lost: 180 bytes in 3 blocks ==5693== possibly lost: 0 bytes in 0 blocks ==5693== still reachable: 0 bytes in 0 blocks ==5693== suppressed: 0 bytes in 0 blocks When the Zend memory manager is turned on, everything is fine. Is this behavior intended? Thanks in advance, Pascal