On Thu, Jun 22, 2017 at 9:12 PM, Jakub Zelenka <bu...@php.net> wrote:
> Ah thanks I see! Just out of interest what changes actually caused it as > it's master only? > It's due to https://github.com/php/php-src/commit/141d1ba9801f742dc5d9ccd06e02b94284c4deb7, which has only been introduced in master. Nikita > On Thu, Jun 22, 2017 at 7:51 PM, Nikita Popov <nikita....@gmail.com> > wrote: > >> On Thu, Jun 22, 2017 at 8:45 PM, Jakub Zelenka <bu...@php.net> wrote: >> >>> Hi Dmitry, >>> >>> I noticed that valgind reports a lot of memleaks for the master and it >>> seems to be related to the freeing of registered classes on shutdown when >>> running cli. I'm wondering if it can be related to your recent changes >>> that >>> were touching that parts. I haven't found the commit that caused but 7.1 >>> is >>> fine. If you don't think that it was related I will try to find it but >>> wanted to check with you first. >>> >>> Here is a part of the output what I'm getting when running valgrind on >>> debug build for master: >>> >>> valgrind --leak-check=full php ext/openssl/tests/openssl_dige >>> st_basic.phpt >>> ... >>> ... (simillar info like this for all loaded extensions like the below) >>> ... >>> ==4101== 648 bytes in 9 blocks are definitely lost in loss record 69 of >>> 70 >>> ==4101== at 0x4C2DB9D: malloc (vg_replace_malloc.c:299) >>> ==4101== by 0xB7DC7D: zend_register_functions (zend_API.c:2304) >>> ==4101== by 0xB7F209: do_register_internal_class (zend_API.c:2714) >>> ==4101== by 0xB7F400: zend_register_internal_class (zend_API.c:2762) >>> ==4101== by 0xB7F2BF: zend_register_internal_class_ex >>> (zend_API.c:2734) >>> ==4101== by 0x64EFAC: zm_startup_dom (php_dom.c:643) >>> ==4101== by 0xB7C211: zend_startup_module_ex (zend_API.c:1873) >>> ==4101== by 0xB7C29B: zend_startup_module_zval (zend_API.c:1888) >>> ==4101== by 0xB8B6B1: zend_hash_apply (zend_hash.c:1507) >>> ==4101== by 0xB7C907: zend_startup_modules (zend_API.c:1999) >>> ==4101== by 0xAB2E71: php_module_startup (main.c:2269) >>> ==4101== by 0xC6B159: php_cli_startup (php_cli.c:431) >>> ==4101== >>> ==4101== 5,592 bytes in 78 blocks are definitely lost in loss record 70 >>> of >>> 70 >>> ==4101== at 0x4C2DB9D: malloc (vg_replace_malloc.c:299) >>> ==4101== by 0xB7DC7D: zend_register_functions (zend_API.c:2304) >>> ==4101== by 0xB7CBB0: zend_register_module_ex (zend_API.c:2062) >>> ==4101== by 0xB7CC8B: zend_register_internal_module (zend_API.c:2077) >>> ==4101== by 0xAB242E: php_register_extensions (main.c:1996) >>> ==4101== by 0xC6A834: php_register_internal_extensions >>> (internal_functions_cli.c:114) >>> ==4101== by 0xAB2E30: php_module_startup (main.c:2253) >>> ==4101== by 0xC6B159: php_cli_startup (php_cli.c:431) >>> ==4101== by 0xC6D40D: main (php_cli.c:1362) >>> ==4101== >>> ==4101== LEAK SUMMARY: >>> ==4101== definitely lost: 9,968 bytes in 142 blocks >>> ==4101== indirectly lost: 0 bytes in 0 blocks >>> ==4101== possibly lost: 0 bytes in 0 blocks >>> ==4101== still reachable: 1,518 bytes in 30 blocks >>> ==4101== suppressed: 0 bytes in 0 blocks >>> ==4101== Reachable blocks (those to which a pointer was found) are not >>> shown. >>> ==4101== To see them, rerun with: --leak-check=full --show-leak-kinds=all >>> ==4101== >>> ==4101== For counts of detected and suppressed errors, rerun with: -v >>> ==4101== ERROR SUMMARY: 40 errors from 40 contexts (suppressed: 0 from 0) >>> >>> Please let me know! Or if anyone else has an idea about the changes that >>> caused it that would be great. >>> >>> Currently it's quite difficult to use vlagrind and find the real issues >>> though... >>> >>> Thanks >>> >>> Jakub >>> >> >> These are arginfo leaks. If arginfo contains type hints, then it is >> copied now, but not freed. There's an incomplete PR for this issue here: >> https://github.com/php/php-src/pull/2462 >> >> Nikita >> >> >
