Bug #80243 [Opn]: OPCache JIT segfaults at startup

Edit report at https://bugs.php.net/bug.php?id=80243&edit=1 ID: 80243 User updated by: jens-erik dot riedel at kippdata dot de Reported by: jens-erik dot riedel at kippdata dot de Summary: OPCache JIT segfaults at startup Status: Open Type: Bug Package: JIT Operating System: RHEL 8.0 PHP Version: 8.0.0rc1 Block user comment: N Private report: N New Comment: The fact that there is an extra efree(libpath) in main/php_ini.c in line 390 may correspond to the fact that this extra 'efree(libpath)` is not present in 8.0.0beta3 and OPCache JIT startup does not crash in 8.0.0beta3. Perhaps the code around line 384 should be revised. IMHO there is a double free for err1 if PHP_WIN32 is defined. Previous Comments: ------------------------------------------------------------------------ [2020-10-20 19:25:28] brainpower at mailbox dot org The following patch has been added/updated: Patch Name: php80_fix_double_free.patch Revision: 1603221928 URL: https://bugs.php.net/patch-display.php?bug=80243&patch=php80_fix_double_free.patch&revision=1603221928 ------------------------------------------------------------------------ [2020-10-20 19:22:09] brainpower at mailbox dot org Urg, brain fart. There's not a return missing, but one efree(libpath) too much! It's a double free error after all. Curiously I wasn't able to reproduce the original issue with the crash in dasm_put() anymore after fixing the double free. I'll attach a patch of what I did... ------------------------------------------------------------------------ [2020-10-20 18:12:50] brainpower at mailbox dot org Yeah, same crash in php_ini.c for me... After a short look into that file, I think there is a return missing after line 377: 368 efree(orig_libpath); 369 efree(err1); 370 efree(libpath); 371 efree(err2); 372 return; 373 } 374 375 efree(orig_libpath); 376 efree(err1); 377 efree(libpath); >> RETURN MISSING HERE?? << 378 } 379 380 #ifdef PHP_WIN32 381 if (!php_win32_image_compatible(handle, &err1)) { .... 387 #endif 388 389 zend_load_extension_handle(handle, libpath); 390 efree(libpath); // theese lines should probably not be reached if(!handle) above is entered... 391 } ------------------------------------------------------------------------ [2020-10-20 16:49:31] jens-erik dot riedel at kippdata dot de I have tried with USE_ZEND_ALLOC=0 (using 8.0.0rc1 on RHEL 8). It crashes again; I don't know if this qualifies as "crashes harder" but at least it crashes differently. $ USE_ZEND_ALLOC=0 /opt/products/php80/8.0.0rc1-1/bin/php -c /opt/instances/php80-fpm/lib/php.ini -d opcache.enable_cli=1 -i free(): double free detected in tcache 2 Aborted (core dumped) Backtrace is as follows: Core was generated by `/opt/products/php80/8.0.0rc1-1/bin/php -c /opt/instances/php80-fpm/lib/php.ini'. Program terminated with signal SIGABRT, Aborted. #0 0x00007f88746e893f in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00007f88746e893f in raise () from /lib64/libc.so.6 #1 0x00007f88746d2c95 in abort () from /lib64/libc.so.6 #2 0x00007f887472bd57 in __libc_message () from /lib64/libc.so.6 #3 0x00007f887473268c in malloc_printerr () from /lib64/libc.so.6 #4 0x00007f8874734155 in _int_free () from /lib64/libc.so.6 #5 0x00007f8875ea9ec1 in php_load_zend_extension_cb (arg=<optimized out>) at /bld/php80/main/php_ini.c:391 #6 0x00007f8875ef80ee in zend_llist_apply (l=l@entry=0x7f8876443f60 <extension_lists>, func=func@entry=0x7f8875ea9e30 <php_load_zend_extension_cb>) at /bld/php80/Zend/zend_llist.c:182 #7 0x00007f8875eaaa47 in php_ini_register_extensions () at /bld/php80/main/php_ini.c:756 #8 0x00007f8875ea3a46 in php_module_startup (sf=<optimized out>, additional_modules=additional_modules@entry=0x0, num_additional_modules=num_additional_modules@entry=0) at /bld/php80/main/main.c:2235 #9 0x0000000000404b6d in php_cli_startup (sapi_module=<optimized out>) at /bld/php80/sapi/cli/php_cli.c:407 #10 0x000000000040453c in main (argc=6, argv=0x1ef3700) at /bld/php80/sapi/cli/php_cli.c:1304 ------------------------------------------------------------------------ [2020-10-20 15:32:09] nikic@php.net Thank you for the investigation, this is rather intriguing. I find is hard to believe that this is an allocator bug (I don't think I've seen one of those in years), it's more likely that something is corrupting the allocator state. There's two simple things that could be tried: 1. Run "USE_ZEND_ALLOC=0 php". That will switch to using the system allocator -- which will possibly make it work, or crash harder... 2. Run "USE_ZEND_ALLOC=0 valgrind php", which might point out memory corruption. (In this case, "USE_ZEND_ALLOC=1 valgrind php" might also be interesting.) ------------------------------------------------------------------------ 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=80243 -- Edit this bug report at https://bugs.php.net/bug.php?id=80243&edit=1