You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
pear install raises error on shutdown in conjunction with ZTS:
pear -c pearrc install --nodeps --packagingroot /root/php-pear-Calendar/BUILDROOT/php-pear-Calendar-0.5.5-10.mga9.x86_64 /root/php-pear-Calendar/SOURCES/Calendar-0.5.5.tgz
shows the followin error in strace:
malloc_consolidate(): unaligned fastbin chunk detected
#0 0x00007f6d9bac5bec in __pthread_kill_implementation () from /lib64/libc.so.6 #1 0x00007f6d9ba792f2 in raise () from /lib64/libc.so.6 #2 0x00007f6d9ba65457 in abort () from /lib64/libc.so.6 #3 0x00007f6d9baba788 in __libc_message () from /lib64/libc.so.6 #4 0x00007f6d9bace98a in malloc_printerr () from /lib64/libc.so.6 #5 0x00007f6d9bacf41c in malloc_consolidate () from /lib64/libc.so.6 #6 0x00007f6d9bad0800 in _int_free () from /lib64/libc.so.6 #7 0x00007f6d9bad2a4b in free () from /lib64/libc.so.6 #8 0x00000000008856e5 in root_buffer_dtor (gc_globals=0x27244f0) at /usr/src/debug/php-8.1.3-2.mga9.x86_64/Zend/zend_gc.c:425 #9 0x0000000000784154 in tsrm_shutdown () at /usr/src/debug/php-8.1.3-2.mga9.x86_64/TSRM/TSRM.c:194 #10 0x00000000006402b7 in main (argc=31, argv=0x2722da0) at /usr/src/debug/php-8.1.3-2.mga9.x86_64/sapi/cli/php_cli.c:1388
This is a new issue in PHP 8.1 with 8.0.x no error is raised.
Do you have a negative return code of pear-install?
I'm not sure why this fails during destruction, but at least the write operation on the filedescriptor fails (since it was already closed). I'm not sure if this is "real" crash reason.
What version of glibc are you using?
I didn't see a problem during regular php runs - and php test cases run w/o problem.
I've just checked glibc, but I don't see when fastbins are used and when normal bin used during malloc. And this test is only active on "fastbins".
Running the command with USE_ZEND_ALLOC=0 valgrind ... gives the following hint:
==957== Invalid read of size 1
==957== at 0x8A0E8C: UnknownInlinedFun (zend_string.h:329)
==957== by 0x8A0E8C: free_ini_entry (zend_ini.c:78)
==957== by 0x832E3C: zend_hash_destroy (zend_hash.c:1591)
==957== by 0x8A13DC: zend_ini_dtor (zend_ini.c:111)
==957== by 0x81D073: executor_globals_dtor (zend.c:808)
==957== by 0x7A2846: ts_free_id (TSRM.c:541)
==957== by 0x81F2CD: zend_shutdown (zend.c:1138)
==957== by 0x7A6158: UnknownInlinedFun (main.c:2413)
==957== by 0x7A6158: php_module_shutdown (main.c:2390)
==957== by 0x64310D: main (php_cli.c:1382)
==957== Address 0x65c12c4 is 4 bytes inside a block of size 48 free'd
==957== at 0x48378E9: free (vg_replace_malloc.c:538)
==957== by 0x832E3C: zend_hash_destroy (zend_hash.c:1591)
==957== by 0x7A50C5: php_request_shutdown (main.c:1871)
==957== by 0x9256ED: do_cli (php_cli.c:1135)
==957== by 0x6430EB: main (php_cli.c:1367)
==957== Block was alloc'd at
==957== at 0x4836751: malloc (vg_replace_malloc.c:307)
==957== by 0x7E4BFC: __zend_malloc (zend_alloc.c:3056)
==957== by 0x8B7403: UnknownInlinedFun (zend_string.h:150)
==957== by 0x8B7403: UnknownInlinedFun (zend_string.h:172)
==957== by 0x8B7403: zend_string_init_interned_request (zend_string.c:313)
==957== by 0x8A1751: zend_register_ini_entries (zend_ini.c:219)
==957== by 0x6668860: ???
==957== by 0x824399: UnknownInlinedFun (zend_API.c:2199)
==957== by 0x824399: zend_startup_module_ex (zend_API.c:2152)
==957== by 0x7314A7: php_load_extension (dl.c:225)
==957== by 0x73167E: php_dl (dl.c:268)
==957== by 0x731729: zif_dl (dl.c:61)
==957== by 0x89928E: UnknownInlinedFun (zend_vm_execute.h:1297)
==957== by 0x89928E: execute_ex (zend_vm_execute.h:55404)
==957== by 0x89F85E: zend_execute (zend_vm_execute.h:59771)
==957== by 0x81FB1A: zend_execute_scripts (zend.c:1792)
I'm glad it is now reproduceable. I'm wondering why this only happens, if the file is given via command line and not, if it is downloaded by php itself. Strange - but some bugs are ;)
I dug into this bug again today: The problem happens because pear is loading the zlib extension dynamically with dl(). This causes the extension to allocate resources with a storage whose lifespan is shorter than the resources themselves. The extension creates interned strings for ini entries during a phase when truly permanent interned strings are read only, so the interned strings are created with a request scope, which is shorter than the ini entries in ZTS builds.
A workaround for this problem is to load the zlib extension earlier by using the extension directive.
Currently the manual for dl() has a note stating that the dl() function is currently not supported in ZTS builds.
I've added the zlib extension to the list of modules at startup for pear. It works. But I leave this one open, in case you found sth. to worry about. Since this can happen in any other case, it might be worth try to omit this error.
Thanks @arnaud-lb for quick response. Is this fix not available in 8.0 as well.? I updated my image to latest version 8..0.30 but still being this issue.Please confirm.
Activity
arnaud-lb commentedon Apr 1, 2022
Hello
I was not able to reproduce with php 8.1.4 zts on ubuntu 20 with the following command:
Do you have any extensions installed ? What is the output of
php -m?mokraemer commentedon Apr 1, 2022
pear command is:
so no comfig is used.
gcc version 12.0.1
glibc-2.35
arnaud-lb commentedon Apr 15, 2022
I tried reproducing with the same configure command, with no luck. Here is the docker file I used:
(I've just removed some shared extensions from the configure command.)
mokraemer commentedon Apr 17, 2022
this is strange - it even happens with my latest backport of php 8.1.5:
https://ftp-stud.hs-esslingen.de/pub/Mirrors/Mageia/distrib/8/x86_64/media/core/backports_testing/
where php-8.0.18 installs without problems.
Do you have a negative return code of pear-install?
I'm not sure why this fails during destruction, but at least the write operation on the filedescriptor fails (since it was already closed). I'm not sure if this is "real" crash reason.
What version of glibc are you using?
I didn't see a problem during regular php runs - and php test cases run w/o problem.
I've just checked glibc, but I don't see when fastbins are used and when normal bin used during malloc. And this test is only active on "fastbins".
arnaud-lb commentedon Apr 17, 2022
Here is a Dockerfile based on mageia 8 and your backport packages:
Here is the output of
docker build -t mageia .:Unfortunately, the pear command returns successfully.
Could you try to adapt this dockerfile to match your environment ?
mokraemer commentedon Apr 18, 2022
I can confirm this one working. But
raises an exception (core dump).
arnaud-lb commentedon Apr 18, 2022
Thank you, I can reproduce the issue now :)
Running the command with
USE_ZEND_ALLOC=0 valgrind ...gives the following hint:The extension in
zif_dliszlib.sophp_request_shutdown (main.c:1871)is this line: https://github.com/php/php-src/blob/php-8.1.5/main/main.c#L1871The crash does not happen with GC disabled, or if
zlibis loaded with-dextension=zlibarnaud-lb commentedon Apr 18, 2022
I will try to dig into this near Friday (unless someones does it first).
Updated Dockerfile with debuginfo and tools:
mokraemer commentedon Apr 19, 2022
I'm glad it is now reproduceable. I'm wondering why this only happens, if the file is given via command line and not, if it is downloaded by php itself. Strange - but some bugs are ;)
arnaud-lb commentedon Apr 22, 2022
I dug into this bug again today: The problem happens because pear is loading the
zlibextension dynamically with dl(). This causes the extension to allocate resources with a storage whose lifespan is shorter than the resources themselves. The extension creates interned strings for ini entries during a phase when truly permanent interned strings are read only, so the interned strings are created with a request scope, which is shorter than the ini entries in ZTS builds.A workaround for this problem is to load the zlib extension earlier by using the extension directive.
Currently the manual for
dl()has a note stating that thedl()function is currently not supported in ZTS builds.nikic commentedon Apr 22, 2022
@arnaud-lb I believe
php-src/Zend/zend_API.c
Line 2973 in 733023b
arnaud-lb commentedon Apr 23, 2022
This removes entries from
registered_zend_ini_directives, but ini entries for temporary modules are registered inEG(ini_entries).So that would be the actual issue. A possible fix would be that temporary modules unregister from
EG(ini_entries)mokraemer commentedon Apr 30, 2022
I've added the zlib extension to the list of modules at startup for pear. It works. But I leave this one open, in case you found sth. to worry about. Since this can happen in any other case, it might be worth try to omit this error.
arnaud-lb commentedon Apr 30, 2022
Thank you for confirming this. A fix is ongoing at #8435
Fix unregistering ini entries of dynamically loaded extension (#8435)
arnaud-lb commentedon May 6, 2022
Fixed in #8435
Thank you @mokraemer
HeenaBansal2009 commentedon Sep 22, 2023
@nikic @arnaud-lb , is this fix available in php 7.4 ?
I didn't find anything in changeling for php 7.4?
I'll appreciate your response on this.
arnaud-lb commentedon Sep 22, 2023
@HeenaBansal2009 this has been fixed in 8.1, but not in 7.4 because this version is not supported anymore (see https://www.php.net/supported-versions.php).
HeenaBansal2009 commentedon Sep 22, 2023
Thanks @arnaud-lb for quick response. Is this fix not available in 8.0 as well.? I updated my image to latest version 8..0.30 but still being this issue.Please confirm.
arnaud-lb commentedon Sep 22, 2023
8.0 is not supported anymore either (except for security issues)