Bug #60637 [Com]: Lexer is full of memory leaks

Edit report at https://bugs.php.net/bug.php?id=60637&edit=1 ID: 60637 Comment by: nikic@php.net Reported by: nlopess@php.net Summary: Lexer is full of memory leaks Status: Open Type: Bug Package: Scripting Engine problem PHP Version: trunk-SVN-2012-01-02 (SVN) Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2012-03-02 14:46:49] nikic@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] nlopess@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