Bug #77683 [Opn->Wfx]: Segfault possibly by strange chars

Edit report at https://bugs.php.net/bug.php?id=77683&edit=1 ID: 77683 Updated by: cmb@php.net Reported by: pascal dot nobus at webservice dot be Summary: Segfault possibly by strange chars -Status: Open +Status: Wont fix Type: Bug Package: *General Issues Operating System: Slackware 14.1 PHP Version: 7.1.26 -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: Active support for PHP 7.1 ended months ago[1], so this issue will not be fixed. If you experience the same problems with an actively supported PHP version, please re-open the ticket and state the PHP version. [1] <http://php.net/supported-versions.php> Previous Comments: ------------------------------------------------------------------------ [2019-03-04 23:13:03] pascal dot nobus at webservice dot be I had several days without any segfaults now. So it's pretty safe to conclude that Apache MPM-event together with mod_php is causing Segfault when doing something with the enviroment or locales. So it's not only non-thread-safe, but also causing crashes. I have no idea that this is something that can be fixed within PHP/apache. ------------------------------------------------------------------------ [2019-03-02 17:26:53] pascal dot nobus at webservice dot be It seems the crashes got less, however I still got some new ones: #0 0x00007f6db5adb36a in __strchr_sse2 () from /lib64/libc.so.6 No symbol table info available. #1 0x00007f6db5a8d8d8 in putenv () from /lib64/libc.so.6 No symbol table info available. #2 0x00007f6db12ae782 in php_putenv_destructor (zv=<optimized out>) at /usr/local/src/php-7.1.26/ext/standard/basic_functions.c:3435 pe = 0x7f6d10e2a900 #0 0x00007f6db5b8acb8 in __strchr_sse42 () from /lib64/libc.so.6 No symbol table info available. #1 0x00007f6db1360654 in _php_import_environment_variables (array_ptr=0x7f6d48001dd0) at /usr/local/src/php-7.1.26/main/php_variables.c:527 buf = "_\000BROKEN_FILENAMES\000{m\177", '\000' <repeats 18 times>, "\220��\233m\177\000\000\060�\003Hm\177\000\000\220��\233m\177\000\000\002\000\000\000\000\000\000\000�\222\071�m\177\000\000�\201�{m\177\000\000@z�{m\177\000\000\000\000\000\000\000\000\000\000�U=�m\177\000\000@��{m\177\000\000\060��\233m\177\000" env = 0x7f6d44030650 p = <optimized out> t = 0x7f6d9bffbb70 "_" alloc_size = 128 nlen = <optimized out> #2 0x00007f6db135fb9f in php_auto_globals_create_env (name=0x27b1c70) at /usr/local/src/php-7.1.26/main/php_variables.c:813 No locals. #0 0x00007f6db5adb36a in __strchr_sse2 () from /lib64/libc.so.6 No symbol table info available. #1 0x00007f6db5a8d8d8 in putenv () from /lib64/libc.so.6 No symbol table info available. #2 0x00007f6db12ae782 in php_putenv_destructor (zv=<optimized out>) at /usr/local/src/php-7.1.26/ext/standard/basic_functions.c:3435 pe = 0x7f6d00c31900 #0 0x00007f6db5adb36a in __strchr_sse2 () from /lib64/libc.so.6 No symbol table info available. #1 0x00007f6db5a8d8d8 in putenv () from /lib64/libc.so.6 No symbol table info available. #2 0x00007f6db12ae782 in php_putenv_destructor (zv=<optimized out>) at /usr/local/src/php-7.1.26/ext/standard/basic_functions.c:3435 pe = 0x7f6d24c31b40 It seems that putenv is also causing crashing (not thread safe?) I'm going to change the worker from mpm_event to mpm_prefork. ------------------------------------------------------------------------ [2019-03-01 20:24:45] pascal dot nobus at webservice dot be I will report if the problem is fixed by putting setlocale in disable_functions. Is it possible that this has something to do with it: 7.0.0 Support for the category parameter passed as a string has been removed. Only LC_* constants can be used as of this version. (the crashes came after upgrading from 5.6) For the MAGICK_THREAD_LIMIT: @putenv( 'MAGICK_THREAD_LIMIT=1' ); isn't safe wrapped for only Imagick. It's in the constructor of class WC_Regenerate_Images_Request which is used for many processes (including WP_Image_Editor_GD) And offcourse there is no policy.xml if Imagick isn't installed at all. However I'm not certain that this crash wasn't a result of previous error with setlocale. ------------------------------------------------------------------------ [2019-03-01 19:55:25] danack@php.net I commented on that wordpress bug. Imagick::setResourceLimit(\Imagick::RESOURCETYPE_THREAD, 1); should be safe to use, (if wrapped in a check for if Imagick exists). But it isn't required if the appropriate entry to one in the policy.xml anyway. Pascal - please can you update the ticket in a few days time to say if disable the other setlocale / putenvs eliminates the crashes? I'm going to leave the ticket open for now, to think about it. ------------------------------------------------------------------------ [2019-03-01 16:46:19] pascal dot nobus at webservice dot be I just had another crash, and yes: all is pointing now towards setlocale. (gdb) bt full #0 0x00007f6db5a8d88d in getenv () from /lib64/libc.so.6 No symbol table info available. #1 0x00007f6db5a80d76 in setlocale () from /lib64/libc.so.6 No symbol table info available. In the script that caused the crash I saw: setlocale(LC_ALL, 'nl_NL'); Because it's impossible to scan all our websites I set setlocale in the disable_functions in php.ini. The website that was calling this function didn't report any errors, nor an error in the php-log. For the MAGICK_THREAD_LIMIT=1 thing: As you can see in our modules list: no imagmagic compiled (couldn't be, as it is not on our servers). However in the WP-plugin woocommerce I did find this call wp-content/plugins/woocommerce/includes/class-wc-regenerate-images-request.php @putenv( 'MAGICK_THREAD_LIMIT=1' ); Theres a reason for this: https://core.trac.wordpress.org/ticket/36534 I tried it myself with a script but no crashes. I have no idea how to prevent these crashes, but maybe the reason for this crash lies with the earlier setlocale. As setlocale in the php-docs say: The locale information is maintained per process, not per thread. If you are running PHP on a multithreaded server API like IIS, HHVM or Apache on Windows, you may experience sudden changes in locale settings while a script is running, though the script itself never called setlocale(). This happens due to other scripts running in different threads of the same process at the same time, changing the process-wide locale using setlocale(). ------------------------------------------------------------------------ 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=77683 -- Edit this bug report at https://bugs.php.net/bug.php?id=77683&edit=1