Bug #79535 [Opn]: PHP crashes with specific opcache.optimization_level

From: Date: Thu, 30 Apr 2020 13:10:08 +0000
Subject: Bug #79535 [Opn]: PHP crashes with specific opcache.optimization_level
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-226854@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=79535&edit=1 ID: 79535 User updated by: roland at nextendweb dot com Reported by: roland at nextendweb dot com Summary: PHP crashes with specific opcache.optimization_level Status: Open Type: Bug Package: opcache Operating System: Windows, Linux PHP Version: 7.3.17 Block user comment: N Private report: N New Comment: Good news! I was able to create a reduced test case where this bug happens. Could you verify that the crash happens for you too? https://www.dropbox.com/s/3jp5dzyfzmurxcc/php-bug-79535.zip?dl=1 Run index.php The desired output: html{padding:0;}Hello World If you open LessCompiler.php and replace protected function newFormatter() { $className = Compressed::class; return new $className; } with protected function newFormatter() { return new Compressed(); } It will work fine. Also when you invalidate opcode cache for LessCompiler.php, then it works for the first load and every other try crashes. Previous Comments: ------------------------------------------------------------------------ [2020-04-30 10:00:41] nikic@php.net I can't do anything about this without a way to reproduce. The only suggestion I have is to make sure that the optimization level is masked with 0xfffeffff, which disables an unsafe (in the sense of "can crash" rather than "can cause misbehavior") optimization, though I doubt that is the actual cause. ------------------------------------------------------------------------ [2020-04-30 09:06:08] cmb@php.net Thanks for the analysis report using PHP 7.3.17! It contains the following slightly different backtrace (unfortunately, again without line numbers, but these might not be that helpful anyway): php7ts!object_and_properties_init+d php7ts!ZEND_NEW_SPEC_VAR_UNUSED_HANDLER+40 php7ts!execute_ex+5f php7ts!zend_call_function+2d0 php7ts!zif_call_user_func_array+da php7ts!ZEND_DO_FCALL_BY_NAME_SPEC_RETVAL_UNUSED_HANDLER+ac php7ts!execute_ex+5f php7ts!zend_execute+1a8 php7ts!zend_execute_scripts+b9 php7ts!php_execute_script+261 php7apache2_4!php_handler+591 Anyhow, assuming that the OPcache instance isn't shared across different PHP configurations, it looks like some combinations of optimizations are not properly supported, which may result in segfaults (likely trying to read offsets of NULL). @roland, I suggest to stick with one of the working optimization levels or just the default (0x7FFEBFFF). ------------------------------------------------------------------------ [2020-04-30 07:57:41] roland at nextendweb dot com Can you download it from here? Is it contains what you need? https://www.dropbox.com/s/qr612f6mkyb14pc/MultipleDumps_MultipleRules.mht?dl=1 ------------------------------------------------------------------------ [2020-04-30 07:25:33] cmb@php.net Thanks for the further info! Can you please try with a recent PHP version on Windows, and provide a *debug* backtrace, see <https://bugs.php.net/bugs-generating-backtrace-win32.php>. ------------------------------------------------------------------------ [2020-04-29 16:37:41] roland at nextendweb dot com I didn't originally used xdebug and xdebug was only on a single server installed. I was able to reproduce this crash on 3 different server and on two xdebug was not installed. So I do not think it is xdebug related. If I added opcache_reset() to my index.php it was good all the time. After removed, it crashed. ------------------------------------------------------------------------ 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=79535 -- Edit this bug report at https://bugs.php.net/bug.php?id=79535&edit=1

« previous php.bugs (#226854) next »