Edit report at https://bugs.php.net/bug.php?id=60637&edit=1
ID: 60637
Updated by: ni...@php.net
Reported by: nlop...@php.net
Summary: Lexer is full of memory leaks
-Status: Open
+Status: Not a bug
Type: Bug
Package: Scripting Engine problem
PHP Version: trunk-SVN-2012-01-02 (SVN)
Block user comment: N
Private report: N
New Comment:
Closing as not a bug. After talking to Rasmus it seems like it is intended
behavior to not free all individual allocations on shutdown and instead rely on
the Zend MM to flush all allocated memory.
Previous Comments:
------------------------------------------------------------------------
[2012-03-02 15:00:04] ni...@php.net
Ah, seems like I specified USE_ZEND_ALLOC=0 incorrectly.
Now getting this valgrind output for the require inexistent file case:
==8944==
==8944== HEAP SUMMARY:
==8944== in use at exit: 68,745 bytes in 2,588 blocks
==8944== total heap usage: 27,424 allocs, 24,836 frees, 1,842,625 bytes
allocated
==8944==
==8944== 136 bytes in 1 blocks are definitely lost in loss record 69 of 138
==8944== at 0x4028876: malloc (vg_replace_malloc.c:236)
==8944== by 0x850BF34: _emalloc (zend_alloc.c:2423)
==8944== by 0x84E40D2: compile_file (zend_language_scanner.l:548)
==8944== by 0x82E4393: phar_compile_file (phar.c:3391)
==8944== by 0x84E4419: compile_filename (zend_language_scanner.l:622)
==8944== by 0x858A90A: ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER
(zend_vm_execute.h:2592)
==8944== by 0x85806C8: execute (zend_vm_execute.h:410)
==8944== by 0x8545111: zend_execute_scripts (zend.c:1272)
==8944== by 0x84A8624: php_execute_script (main.c:2473)
==8944== by 0x868E8D0: do_cli (php_cli.c:983)
==8944== by 0x868FC4F: main (php_cli.c:1356)
==8944==
==8944== 211 bytes in 1 blocks are definitely lost in loss record 77 of 138
==8944== at 0x402896C: realloc (vg_replace_malloc.c:525)
==8944== by 0x850C08F: _erealloc (zend_alloc.c:2444)
==8944== by 0x84AC6F0: xbuf_format_converter (spprintf.c:777)
==8944== by 0x84AC9DC: vspprintf (spprintf.c:799)
==8944== by 0x84ACA3D: spprintf (spprintf.c:818)
==8944== by 0x84A3CEC: php_verror (main.c:832)
==8944== by 0x84A3FDC: php_error_docref0 (main.c:865)
==8944== by 0x84A5642: php_message_handler_for_zend (main.c:1372)
==8944== by 0x8543DE6: zend_message_dispatcher (zend.c:972)
==8944== by 0x84E41AD: compile_file (zend_language_scanner.l:568)
==8944== by 0x82E4393: phar_compile_file (phar.c:3391)
==8944== by 0x84E4419: compile_filename (zend_language_scanner.l:622)
==8944==
==8944== 252 (136 direct, 116 indirect) bytes in 1 blocks are definitely lost
in loss record 80 of 138
==8944== at 0x4028876: malloc (vg_replace_malloc.c:236)
==8944== by 0x850BF34: _emalloc (zend_alloc.c:2423)
==8944== by 0x84E40D2: compile_file (zend_language_scanner.l:548)
==8944== by 0x82E4393: phar_compile_file (phar.c:3391)
==8944== by 0x854500D: zend_execute_scripts (zend.c:1264)
==8944== by 0x84A8624: php_execute_script (main.c:2473)
==8944== by 0x868E8D0: do_cli (php_cli.c:983)
==8944== by 0x868FC4F: main (php_cli.c:1356)
==8944==
==8944== LEAK SUMMARY:
==8944== definitely lost: 483 bytes in 3 blocks
==8944== indirectly lost: 116 bytes in 4 blocks
==8944== possibly lost: 0 bytes in 0 blocks
==8944== still reachable: 68,146 bytes in 2,581 blocks
==8944== suppressed: 0 bytes in 0 blocks
==8944== Reachable blocks (those to which a pointer was found) are not shown.
==8944== To see them, rerun with: --leak-check=full --show-reachable=yes
==8944==
==8944== For counts of detected and suppressed errors, rerun with: -v
==8944== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 35 from 6)
I'm not sure how expected or not this is. All your cases are ones which will
cause a zend_bailout and unclean shutdown. I'm not sure those can really be
cleaned up correctly.
------------------------------------------------------------------------
[2012-03-02 14:46:49] ni...@php.net
I can't reproduce this. How did you detect these leaks / in which form did they
manifest?
------------------------------------------------------------------------
[2012-01-02 14:02:34] nlop...@php.net
Description:
------------
zend_language_scanner.l has quite a big number of leaks:
- require('non-existent-file') - 2 leaks
- include('file-with-parse-error')
- every usage of zend_copy_value must be audited -- on a parse error it's
likely the memory will be leaked.
(run with USE_ZEND_ALLOC=0)
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=60637&edit=1
