Edit report at https://bugs.php.net/bug.php?id=63950&edit=1
ID: 63950 User updated by: hufeng1987 at gmail dot com Reported by: hufeng1987 at gmail dot com Summary: Lot's of memory leaks detected -Status: Feedback +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: 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? Previous Comments: ------------------------------------------------------------------------ [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) ------------------------------------------------------------------------ [2013-01-09 08:57:51] paj...@php.net An easy way to provide more info is to run php under valgrind. It could help to locate the issue (for obvious ones). But at the end we may need something to reproduce it. ------------------------------------------------------------------------ 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
