Edit report at https://bugs.php.net/bug.php?id=63950&edit=1
ID: 63950 Updated by: larue...@php.net Reported by: hufeng1987 at gmail dot com Summary: Lot's of memory leaks detected Status: Open Type: Bug Package: FPM related Operating System: CentOS 5.8 PHP Version: 5.4.10 Block user comment: N Private report: N New Comment: it depends on what the codes is, and whether it is a known issue. Previous Comments: ------------------------------------------------------------------------ [2013-01-10 04:46:55] hufeng1987 at gmail dot com i have configured the core dump environment. still waiting for the core dump. it's not always segfault, i hope i could catch it . I want to ask, if some code cause php segfault, it's code's problem or the php's problem? should we fixed it by change the code ? or need to fixed by php upstream? ------------------------------------------------------------------------ [2013-01-10 04:42:43] larue...@php.net could you please give us the backtrace of the segfault you mentioned? ------------------------------------------------------------------------ [2013-01-09 23:52:53] hufeng1987 at gmail dot com it's this APC bug? some times it cause PHP segmentation fault ------------------------------------------------------------------------ [2013-01-09 15:44:21] ras...@php.net The Valgrind output looks normal. There are a couple of intentional at-exit leaks in APC. These are not relevant since they aren't per-request. It is simply memory only allocated at process startup and not freed, relying instead on process exit to clear it. ------------------------------------------------------------------------ [2013-01-09 09:10:52] hufeng1987 at gmail dot com i found following log ------------------------------------------------------------------------------ ==3523== ==3523== HEAP SUMMARY: ==3523== in use at exit: 1,712 bytes in 15 blocks ==3523== total heap usage: 997,631 allocs, 997,616 frees, 333,021,308 bytes allocated ==3523== ==3523== Searching for pointers to 15 not-freed blocks ==3523== Checked 966,304 bytes ==3523== ==3523== 96 (16 direct, 80 indirect) bytes in 1 blocks are definitely lost in loss record 10 of 15 ==3523== at 0x4A0610C: malloc (vg_replace_malloc.c:195) ==3523== by 0x8CDA128: ??? ==3523== by 0x8CF21A9: ??? ==3523== by 0x8CDD617: ??? ==3523== by 0x8CDE041: ??? ==3523== by 0x99D775: zend_startup_module_ex (zend_API.c:1661) ==3523== by 0x9A96D2: zend_hash_apply (zend_hash.c:716) ==3523== by 0x99DCBB: zend_startup_modules (zend_API.c:1788) ==3523== by 0x8FDEC1: php_module_startup (main.c:2200) ==3523== by 0xAFAA5B: php_cli_startup (php_cli.c:414) ==3523== by 0xAFD368: main (php_cli.c:1344) ==3523== ==3523== LEAK SUMMARY: ==3523== definitely lost: 16 bytes in 1 blocks ==3523== indirectly lost: 80 bytes in 1 blocks ==3523== possibly lost: 0 bytes in 0 blocks ==3523== still reachable: 1,616 bytes in 13 blocks ==3523== suppressed: 0 bytes in 0 blocks ==3523== Reachable blocks (those to which a pointer was found) are not shown. ==3523== To see them, rerun with: --leak-check=full --show-reachable=yes ==3523== ==3523== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 33 from 6) --3523-- --3523-- used_suppression: 29 zlib-1.2.x trickyness (1a): See http://www.zlib.net/zlib_faq.html#faq36 --3523-- used_suppression: 4 dl-hack3 ==3523== ==3523== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 33 from 6) ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63950 -- Edit this bug report at https://bugs.php.net/bug.php?id=63950&edit=1
