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_digest_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
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_digest_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
Ah thanks I see! Just out of interest what changes actually caused it as
it's master only?
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/2462Nikita
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.ppv@gmail.com
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/2462Nikita