Bug #78175 [Com]: Preloading segfaults at preload time and at runtime

Edit report at https://bugs.php.net/bug.php?id=78175&edit=1 ID: 78175 Comment by: nicolas dot grekas+php at gmail dot com Reported by: nicolas dot grekas+php at gmail dot com Summary: Preloading segfaults at preload time and at runtime Status: Closed Type: Bug Package: opcache PHP Version: 7.4.0alpha1 Assigned To: dmitry Block user comment: N Private report: N New Comment: Sorry, this still segfaults for me, here is the code: https://github.com/nicolas-grekas/symfony/releases/download/php-bugs/preload-php-bug-78175.zip Previous Comments: ------------------------------------------------------------------------ [2019-06-24 17:38:52] dmitry@php.net Should be fixed by https://github.com/php/php-src/commit/0f29fb5cd81d9df4829bc63f704019df910b3075 ------------------------------------------------------------------------ [2019-06-21 10:30:25] dmitry@php.net A partial fix is available at https://github.com/php/php-src/compare/PHP-7.4...dstogov:bug78175?expand=1 It needs to be extended to support static variables of methods. ------------------------------------------------------------------------ [2019-06-20 12:30:41] nicolas dot grekas+php at gmail dot com > Although, this is a bug, it's also an interesting unexpected side effect, that allow > initialization and preloading of big arrays as static properties (e.g. application configuration) While funny, that's not that interesting to keep: if one wants this, it's always possible to generate a file with the array and load it. Preloading the default static value is what would be the most expected, to me at least :) ------------------------------------------------------------------------ [2019-06-19 09:22:31] dmitry@php.net The problem caused by assignment object to static property of preloaded class, and opcache doesn't expect objects... A simpler way to reproduce: preload.php ----------- <?php class Loader { static private $loader; static function getLoader() { if (null !== self::$loader) { return self::$loader; } return self::$loader = new Loader(); } } Loader::getLoader(); ?> $ USE_ZEND_ALLOC=0 valgrind sapi/cli/php -dopcache.preload=preload.php -r 'var_dump(get_class(Loader::getLoader()));' Although, this is a bug, it's also an interesting unexpected side effect, that allow initialization and preloading of big arrays as static properties (e.g. application configuration) ------------------------------------------------------------------------ [2019-06-19 07:48:49] dmitry@php.net I don't see crash, but got the following valgrind error on first request (modification of vendor/symfony/dependency-injection/Dumper/PhpDumper.php is not required). ==17283== Invalid read of size 4 ==17283== at 0x87D1339: ZEND_GET_CLASS_SPEC_CV_UNUSED_HANDLER (zend_vm_execute.h:47674) ==17283== by 0x87DBF1A: execute_ex (zend_vm_execute.h:60625) ==17283== by 0x87DC538: zend_execute (zend_vm_execute.h:61077) ==17283== by 0x8728F00: zend_execute_scripts (zend.c:1657) ==17283== by 0x86B656B: php_execute_script (main.c:2680) ==17283== by 0x87E5E72: php_cli_server_dispatch_script (php_cli_server.c:1983) ==17283== by 0x87E6498: php_cli_server_dispatch (php_cli_server.c:2158) ==17283== by 0x87E6BF9: php_cli_server_recv_event_read_request (php_cli_server.c:2374) ==17283== by 0x87E6EEE: php_cli_server_do_event_for_each_fd_callback (php_cli_server.c:2452) ==17283== by 0x87E3B4C: php_cli_server_poller_iter_on_active (php_cli_server.c:841) ==17283== by 0x87E6F88: php_cli_server_do_event_for_each_fd (php_cli_server.c:2475) ==17283== by 0x87E6FE2: php_cli_server_do_event_loop (php_cli_server.c:2485) ==17283== Address 0xa5caeb4 is 1,148 bytes inside a block of size 65,536 free'd ==17283== at 0x4036729: free (vg_replace_malloc.c:540) ==17283== by 0x86FC3F2: _efree_custom (zend_alloc.c:2392) ==17283== by 0x86FC4EF: _efree (zend_alloc.c:2512) ==17283== by 0x86FDDD2: zend_arena_destroy (zend_arena.h:46) ==17283== by 0x86FE860: shutdown_compiler (zend_compile.c:384) ==17283== by 0x872813B: zend_deactivate (zend.c:1185) ==17283== by 0x86B5640: php_request_shutdown (main.c:1975) ==17283== by 0x7EA098F: accel_finish_startup (ZendAccelerator.c:4353) ==17283== by 0x7E9D284: accel_post_startup (ZendAccelerator.c:2969) ==17283== by 0x8727D36: zend_post_startup (zend.c:992) ==17283== by 0x86B5FD7: php_module_startup (main.c:2403) ==17283== by 0x87E2ED8: sapi_cli_server_startup (php_cli_server.c:486) ==17283== Block was alloc'd at ==17283== at 0x40356A4: malloc (vg_replace_malloc.c:309) ==17283== by 0x86FCE7E: __zend_malloc (zend_alloc.c:2895) ==17283== by 0x86FC39C: _malloc_custom (zend_alloc.c:2383) ==17283== by 0x86FC48E: _emalloc (zend_alloc.c:2502) ==17283== by 0x86FDD7F: zend_arena_create (zend_arena.h:34) ==17283== by 0x86FE7A2: init_compiler (zend_compile.c:365) ==17283== by 0x8728011: zend_activate (zend.c:1151) ==17283== by 0x86B528D: php_request_startup (main.c:1836) ==17283== by 0x7EA08C6: accel_finish_startup (ZendAccelerator.c:4324) ==17283== by 0x7E9D284: accel_post_startup (ZendAccelerator.c:2969) ==17283== by 0x8727D36: zend_post_startup (zend.c:992) ==17283== by 0x86B5FD7: php_module_startup (main.c:2403) ------------------------------------------------------------------------ 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=78175 -- Edit this bug report at https://bugs.php.net/bug.php?id=78175&edit=1