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:
The segfaults are also occurring on apache mpm-prefork, which is non-threaded
Previous Comments:
------------------------------------------------------------------------
[2019-03-01 08:28:12] nikic@php.net
Note that thread-safety in PHP 7.0 and 7.1 is pretty thoroughly broken. If you're running in a
threaded environment, then PHP 7.2 (or newer) is needed.
------------------------------------------------------------------------
[2019-03-01 07:15:12] pascal dot nobus at webservice dot be
Danack:
- there is nog imagemagic on this system.
- sites are Wordpress-5.1, Wordpress-4.9.9, Drupal-8.2.6, so no special things that is calling
setlocale.
It seems to me that disabling opcache helped a bit (4 Segfault in 24h, insteadoff 10-20).
Another thought that is was hardware, or the fact that apache is mpm_event (with php compiled as
mod_php) was also ruled out because I see the same effect on other servers (also ones compiled with
mpm_prefork).
------------------------------------------------------------------------
[2019-03-01 03:16:27] danack@php.net
Please could you also try to find what is calling setlocale and seeing if that can be disabled?
------------------------------------------------------------------------
[2019-03-01 03:03:19] danack@php.net
So possibly this might be an altering the environment issue.
One of the stacks appears to be something writing "MAGICK_THREAD_LIMIT=1" into the
environment.
This can also be achieve by editing the policy.xml file that was installed by ImageMagick, that will
be on your system somewhere.
Either editing or adding an entry for thread, like:
<policy domain="resource" name="thread" value="1"/>
Can you try doing that, and seeing if that at least removes those entries from your system?
------------------------------------------------------------------------
[2019-03-01 03:00:11] danack@php.net
So.
I'm just going to make some notes.
Two bits of the stack traces have:
#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.
And:
#0 0x00007f6db5a8d88d in getenv () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007f6db5a80d76 in setlocale () from /lib64/libc.so.6
I've known setlocale is not thread safe - but apparently neither is getenv() + putenv()
From http://man7.org/linux/man-pages/man3/getenv.3.html> Concurrently calling this function is safe, provided that the environment remains unchanged.http://man7.org/linux/man-pages/man7/attributes.7.html
under 'Other safety remarks - env'
> Functions marked with env as an MT-Safety issue access the> environment with getenv(3) or similar, without any guards to> ensure safety in the presence of concurrent modifications.>> We do not mark these functions as MT-Unsafe, however, because> functions that modify the environment are all marked with> const:env and regarded as unsafe. Being unsafe, the latter> are not to be called when multiple threads are running or> asynchronous signals are enabled, and so the environment can> be considered effectively constant in these contexts, which> makes the former safe.
------------------------------------------------------------------------
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