|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #75882 a simple way for segfaults in threadsafe php just with configuration
Submitted: 2018-01-29 08:02 UTC Modified: 2018-02-01 12:27 UTC
From: hajo dot locke at gmx dot de Assigned: ab (profile)
Status: Closed Package: Apache2 related
PHP Version: 7.2.1 OS: Ubuntu 16.04
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: hajo dot locke at gmx dot de
New email:
PHP Version: OS:


 [2018-01-29 08:02 UTC] hajo dot locke at gmx dot de
This is a easy way to have massive segfaults in threadsafe php, just without code, only configuration is needed.

- compile a minimal threadsafe and enable thread safety
./configure --disable-all  --enable-static --prefix=/usr --with-apxs2=/usr/bin/apxs2 --enable-maintainer-zts

- just load this into apache2. no further configuration needed.
LoadModule php7_module /usr/lib/apache2/modules/

- activate a threadsafe mpm in apache like mpm_worker/mpm_event
a2enmod mpm_event

- add a php_value directive in VHost-Config for this particular VHost along with a php_value directive in .htaccess in docroot of this VHost.

It is not needed to request a php-file, just requesting a small static file is enough. The smaller the requested file and higher requests per second the higher is count of segfaults. you can do some mass-requests with ab from apache2-utils or h2load.

Test script:

Expected result:
i expect to have no segfaults and every single request should be served fine. 

Actual result:
You will see massive segfaults and failed requests. threadsafe php is currently not able to edit environment of each request safely.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2018-01-29 08:58 UTC]
-Status: Open +Status: Feedback
 [2018-01-29 08:58 UTC]
Thanks for the report. As discussed on the ML, this quick description didn't reproduce any crash. Please put 

- the backtrace you receive
- the concrete configuration reproducing the crash

 [2018-01-29 08:59 UTC]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read for *NIX and for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

 [2018-01-29 09:59 UTC] hajo dot locke at gmx dot de
-Status: Feedback +Status: Open
 [2018-01-29 09:59 UTC] hajo dot locke at gmx dot de
I was not able to get a core-file. I followed alternative way and started httpd within gdb by:

gdb /usr/sbin/httpd
   run -X

I started the requests and got this:

[Thread 0x7fffc96c1700 (LWP 29479) exited]

Thread 52 "httpd" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffbe7f4700 (LWP 29493)]
0x00007ffff12aca38 in _efree () from /usr/lib/apache2/modules/
(gdb) bt
#0  0x00007ffff12aca38 in _efree () from /usr/lib/apache2/modules/
#1  0x00007ffff13066e9 in ?? () from /usr/lib/apache2/modules/
#2  0x00007ffff130b1fa in zend_hash_destroy () from /usr/lib/apache2/modules/
#3  0x00007ffff13f8bc9 in ?? () from /usr/lib/apache2/modules/
#4  0x00007ffff7728e3e in apr_pool_destroy () from /usr/lib/x86_64-linux-gnu/
#5  0x00007ffff26ededc in ?? () from /usr/lib/apache2/modules/
#6  0x00007ffff26ee067 in ?? () from /usr/lib/apache2/modules/
#7  0x00007ffff270c82b in ?? () from /usr/lib/apache2/modules/
#8  0x00007ffff26f9e12 in ?? () from /usr/lib/apache2/modules/
#9  0x00007ffff771fb76 in apr_hash_do () from /usr/lib/x86_64-linux-gnu/
#10 0x00007ffff270e1ef in ?? () from /usr/lib/apache2/modules/
#11 0x00007ffff26fbafb in ?? () from /usr/lib/apache2/modules/
#12 0x00007ffff2704d33 in ?? () from /usr/lib/apache2/modules/
#13 0x00007ffff26f175e in ?? () from /usr/lib/apache2/modules/
#14 0x00007ffff26f7cb1 in ?? () from /usr/lib/apache2/modules/
#15 0x00005555555b6fc0 in ap_run_process_connection ()
#16 0x00007ffff1a64038 in ?? () from /usr/lib/apache2/modules/
#17 0x00007ffff1a64a1d in ?? () from /usr/lib/apache2/modules/
#18 0x00007ffff74f86ba in start_thread () from /lib/x86_64-linux-gnu/
#19 0x00007ffff722e41d in clone () from /lib/x86_64-linux-gnu/

If i remove from Apache, no error is happen.

This is my VHost-Config. I run this tests with http2-Configuration, but should not make any difference.

<IfModule mod_ssl.c>
  NameVirtualHost *:443
  SSLStrictSNIVHostCheck off
  <VirtualHost *:443>
    DocumentRoot /public_html
    php_value memory_limit 55M
    ScriptAlias /cgi-bin/ "/public_html/cgi-bin/"
    ScriptAlias /cgi-fpm/ "/public_html/myuser"
    SSLEngine on
    SSLCertificateFile /etc/mycerts/mycert.pem
    SSLCertificateKeyFile /etc/mycerts/mycert.pem
    SSLCACertificateFile /etc/mycerts/mycert.pem
    SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
    SetEnvIf User-Agent ".*MSIE.*" \
    nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0
    <IfModule http2_module>
        Protocols h2 http/1.1
 [2018-01-29 17:40 UTC]
Thanks for more info. I can now reproduce the crash and investigating a way to fix.

Btw., the configuration misses "AllowOverride all". That might might be also a temp solution for you, as "AllowOverride none" is viable in your situation.

 [2018-01-31 08:47 UTC] hajo dot locke at gmx dot de
Nice to see it is reproducable.
What is typical roadmap for this, how long does it take to have a fix in a new php-release?
We have a very easy way to produce crashes in threadsafe-php. iam wondering nobody before mentioned this behaviour.
On the other hand i think threadsafe php will not have a high priority for fixes.
What do you think?
 [2018-01-31 19:29 UTC]
-Status: Open +Status: Feedback
 [2018-01-31 19:29 UTC]

I've just pushed a patch fixing this issue. Please test the current 7.2 dev.

 [2018-02-01 08:05 UTC] hajo dot locke at gmx dot de
-Status: Feedback +Status: Open
 [2018-02-01 08:05 UTC] hajo dot locke at gmx dot de

tried 7.2-dev and i see no segfaults any more. i think your patch did it.
Great, thanks for this. Do you think this patch will be applied to other active PHP-Versions?

 [2018-02-01 12:27 UTC]
-Status: Open +Status: Closed -Assigned To: +Assigned To: ab
 [2018-02-01 12:27 UTC]
Many thanks for the checks! Yeah, I'm going to check to backport for 7.1. Whereby for the thread safe variant I'd desperately recommend 7.2.

PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Apr 16 17:01:30 2024 UTC