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

From: Date: Mon, 04 Mar 2019 23:13:03 +0000
Subject: Bug #77683 [Opn]: Segfault possibly by strange chars
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-219842@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=77683&edit=1 ID: 77683 User updated by: pascal dot nobus at webservice dot be Reported by: pascal dot nobus at webservice dot be Summary: Segfault possibly by strange chars Status: Open Type: Bug Package: *General Issues Operating System: Slackware 14.1 PHP Version: 7.1.26 Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [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(). ------------------------------------------------------------------------ [2019-03-01 12:27:21] danack@php.net > there is nog imagemagic on this system. Whether or not ImageMagick is on the system, something is called putenv with the string "MAGICK_THREAD_LIMIT=1". From your crash log: #1 0x00007f6db12af58e in zif_putenv (execute_data=<optimized out>, return_value=0x7f6d9eff2730) at /usr/local/src/php-7.1.26/ext/standard/basic_functions.c:4178 setting = 0x7f6d829f19a8 "MAGICK_THREAD_LIMIT=1" setting_len = 21 p = 0x7f6d423e0a4b "" env = 0x7f6d6c02f778 pe = {putenv_string = 0x7f6d8b26b438 "MAGICK_THREAD_LIMIT=1", previous_value = 0x0, key = 0x7f6d423e0a38 "MAGICK_THREAD_LIMIT", key_len = 19} > so no special things that is calling setlocale. Again, the crash log says that's exactly where one of the crashes comes from: #1 0x00007f6db5a80d76 in setlocale () from /lib64/libc.so.6 No symbol table info available. #2 0x00007f6db12e5de0 in zif_setlocale (execute_data=<optimized out>, return_value=0x7f6d9bfec640) For reference, I can see that there are some setlocale calls in Drupal: https://github.com/drupal/core/blob/6864b728155310851b3919e41c0d32941c5e62ae/lib/Drupal/Core/DrupalKernel.php#L1028 It's not guaranteed to be the cause, but seeing as that is where the errors are occurring, it does seem worth the effort to track these down and try removing them to see if that fixes the problem. ------------------------------------------------------------------------ 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

« previous php.bugs (#219842) next »