php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #67861 after opcache reset all apache children segfault
Submitted: 2014-08-19 07:04 UTC Modified: 2014-08-29 08:07 UTC
From: php at bof dot de Assigned:
Status: Closed Package: opcache
PHP Version: 5.5.16 OS: openSUSE 11.4
Private report: No CVE-ID: None
 [2014-08-19 07:04 UTC] php at bof dot de
Description:
------------
After upgrading from PHP 5.4.29 with APC, to 5.5.15 with opcache, on an official php.net mirror (de2.php.net), I can consistently (tested two times :) crash and burn things by triggering opcache reset through the ocp.php interface.

Immediately after the reset, almost all apache children start to segfault. See the apache error_log excerpt below.

This is with the opcache bundled with PHP 5.5.15, self-compiled against the exact apache version (opensuse 11.4 evergreen apache 2.2.17-80.1.x86_64) that is running on the machine.

opcache.ini:

zend_extension=/opt/php/extensions/opcache.so
; see https://github.com/zendtech/ZendOptimizerPlus
opcache.memory_consumption=512
opcache.interned_strings_buffer=64
opcache.max_wasted_percentage=50
opcache.max_accelerated_files=8000
opcache.fast_shutdown=1
opcache.revalidate_freq=0
opcache.save_comments=0
; opcache.blacklist_filename=/opt/php/ini.d/opcache.blacklist
opcache.error_log=/tmp/opcache.errors
opcache.log_verbosity_level=4

PHP 5.5.15 compiled with this configure call:

./configure \
        --prefix=$DIR \
        --bindir=$DIR/bin \
        --libdir=$DIR \
        --includedir=$DIR/include \
        --mandir=$DIR/man \
        --with-apxs2=/usr/sbin/apxs2 \
        --with-config-file-path=$DIR \
        --with-config-file-scan-dir=$DIR/ini.d \
        --with-zend-vm=GOTO \
        --enable-re2c-cgoto \
        --disable-cgi \
        --enable-bcmath \
        --enable-calendar \
        --enable-exif \
        --enable-ftp \
        --enable-intl \
        --enable-mbstring \
        --enable-pcntl \
        --enable-soap \
        --enable-sockets \
        --enable-zip \
        --enable-opcache \
        --with-openssl \
        --with-zlib \
        --with-bz2 \
        --with-curl \
        --with-gd \
        --enable-gd-native-ttf \
        --with-jpeg-dir=/usr/include \
        --with-gettext \
        --with-gmp \
        --enable-mysqlnd \
        --with-mysqli \
        --with-readline \
        --with-recode \
        --with-xmlrpc \
        --with-xsl \
        --with-pear \
        --with-freetype-dir=/usr/include \
        --with-mhash \
        --with-mcrypt \

Apache error_log excerpt:

Tue Aug 19 08:34:17 2014 (31894): Message Cached script '/srv/www/htdocs/phpweb/include/results.inc'
Tue Aug 19 08:34:19 2014 (31921): Message Cached script '/srv/www/htdocs/phpweb/manual/change.php'
Tue Aug 19 08:34:20 2014 (31898): Debug Restart Scheduled!
Tue Aug 19 08:34:22 2014 (31910): Debug Restarting!
Tue Aug 19 08:34:22 2014 (31910): Message Cached script '/srv/www/htdocs/phpweb/manual/ro/sqlite3.loadextension.php'
[Tue Aug 19 08:34:23 2014] [notice] child pid 31910 exit signal Segmentation fault (11)
[Tue Aug 19 08:34:24 2014] [notice] child pid 31911 exit signal Segmentation fault (11)
[Tue Aug 19 08:34:35 2014] [notice] child pid 31898 exit signal Segmentation fault (11)
[Tue Aug 19 08:34:35 2014] [notice] child pid 31899 exit signal Segmentation fault (11)
Tue Aug 19 08:34:40 2014 (31917): Message Cached script '/srv/www/htdocs/phpweb/manual/it/function.trader-ht-sine.php'
[Tue Aug 19 08:34:41 2014] [notice] child pid 31917 exit signal Segmentation fault (11)


Expected result:
----------------
no crash

Actual result:
--------------
crash

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-08-19 07:10 UTC] php at bof dot de
Just to make the report complete: the error_log messages correspond to an opcache reset I tried a minute after freshly restarting the apache process. A previous instance occurred after running for half a day with the interned string table full (which was the reason why I wanted to try a reset); so, the problem occurs regardless of how full the cache is.
 [2014-08-22 15:29 UTC] php at bof dot de
-PHP Version: 5.5.15 +PHP Version: 5.5.16
 [2014-08-22 15:29 UTC] php at bof dot de
Fully reproducable using PHP 5.5.16, built the same way described previously.
 [2014-08-24 07:22 UTC] laruence@php.net
-Status: Open +Status: Feedback
 [2014-08-24 07:22 UTC] laruence@php.net
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
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php 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.


 [2014-08-29 08:07 UTC] php at bof dot de
-Status: Feedback +Status: Closed
 [2014-08-29 08:07 UTC] php at bof dot de
Really strange... No longer reproducable after installing a debug build of PHP on Monday, and setting everything up so that apache would dump core (Hint: CoreDumpDirectory required in apache config, or it doesn't dump - might be good to mention that in the backtrace docs).

I hit the opcache reset thing several dozen times during the week, and never again saw a coredump. Also went back to the non-debug build for a day, and could still not reproduce it.

Closing this bug...
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 21 13:01:31 2024 UTC