go to bug id or search bugs for
As root, I ran the php-fpm executable and got this error.
I needed to run this manually to debug a different crash.
php-fpm: /php-src/ext/opcache/ZendAccelerator.c:634: accel_replace_string_by_process_permanent: Assertion `0' failed.
Thread 1 "php-fpm" received signal SIGABRT, Aborted.
0x00007ffff4cc5428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
#0 0x00007ffff4cc5428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1 0x00007ffff4cc702a in __GI_abort () at abort.c:89
#2 0x00007ffff4cbdbd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x7fffecc8d6d9 "0", file=file@entry=0x7fffecc8d6a0 "/php-src/ext/opcache/ZendAccelerator.c", line=line@entry=634,
function=function@entry=0x7fffecc8dd80 <__PRETTY_FUNCTION__.16352> "accel_replace_string_by_process_permanent") at assert.c:92
#3 0x00007ffff4cbdc82 in __GI___assert_fail (assertion=0x7fffecc8d6d9 "0", file=0x7fffecc8d6a0 "/php-src/ext/opcache/ZendAccelerator.c", line=634, function=0x7fffecc8dd80 <__PRETTY_FUNCTION__.16352> "accel_replace_string_by_process_permanent")
#4 0x00007fffecc0af34 in accel_replace_string_by_process_permanent (str=0x7fffdb3b3030) at /php-src/ext/opcache/ZendAccelerator.c:634
#5 0x00007fffecc0a960 in accel_copy_permanent_strings (new_interned_string=0x7fffecc0aee0 <accel_replace_string_by_process_permanent>) at /php-src/ext/opcache/ZendAccelerator.c:558
#6 0x00007fffecc0afff in accel_use_permanent_interned_strings () at /php-src/ext/opcache/ZendAccelerator.c:662
#7 0x00007fffecc10468 in accel_shutdown () at /php-src/ext/opcache/ZendAccelerator.c:2760
#8 0x00007fffecc12dfe in zm_shutdown_zend_accelerator (type=1, module_number=54) at /php-src/ext/opcache/zend_accelerator_module.c:434
#9 0x0000000000b4a3c9 in module_destructor (module=0x1a27e20) at /php-src/Zend/zend_API.c:2564
#10 0x0000000000b3d5f9 in module_destructor_zval (zv=0x7fffffffdc60) at /php-src/Zend/zend.c:690
#11 0x0000000000b54c62 in _zend_hash_del_el_ex (ht=0x17807e0 <module_registry>, idx=53, p=0x180b680, prev=0x0) at /php-src/Zend/zend_hash.c:996
#12 0x0000000000b54d42 in _zend_hash_del_el (ht=0x17807e0 <module_registry>, idx=53, p=0x180b680) at /php-src/Zend/zend_hash.c:1019
#13 0x0000000000b562c7 in zend_hash_graceful_reverse_destroy (ht=0x17807e0 <module_registry>) at /php-src/Zend/zend_hash.c:1475
#14 0x0000000000b47f0b in zend_destroy_modules () at /php-src/Zend/zend_API.c:2008
#15 0x0000000000b3db41 in zend_shutdown () at /php-src/Zend/zend.c:901
#16 0x0000000000aa3551 in php_module_shutdown () at /php-src/main/main.c:2414
#17 0x0000000000c42c5e in fpm_php_cleanup (which=2, arg=0x0) at /php-src/sapi/fpm/fpm/fpm_php.c:197
#18 0x0000000000c35247 in fpm_cleanups_run (type=2) at /php-src/sapi/fpm/fpm/fpm_cleanup.c:45
#19 0x0000000000c4ac24 in fpm_unix_init_main () at /php-src/sapi/fpm/fpm/fpm_unix.c:540
#20 0x0000000000c33e0f in fpm_init (argc=1, argv=0x7fffffffe468, config=0x0, prefix=0x0, pid=0x0, test_conf=0, run_as_root=0, force_daemon=-1, force_stderr=0) at /php-src/sapi/fpm/fpm/fpm.c:61
#21 0x0000000000c41d73 in main (argc=1, argv=0x7fffffffe468) at /php-src/sapi/fpm/fpm/fpm_main.c:1861
Add a Patch
Add a Pull Request
Nikita, input on this?
Reassigning to weltling, who worked on the ZTS interning and probably knows more about this.
For reference, this is the triggered assertion: https://github.com/php/php-src/blob/e164b3835ec5b8888253eeb2d9105747e6306f0f/ext/opcache/ZendAccelerator.c#L634
I came across with this issue yesterday.
This does not seem to relate to ZTS build. Assuming the assertion is valid, it seems some kind of object initialization or memory error is involved.
Try to build this with --enable-debug
You'll see the assertion error in many test scripts. In this case, it seems my changes in ext/filter triggered the assertion on master branch.
I don't look into this issue in detail yet, but I'm suspecting object initialization since I usually don't write code that creates object within PHP. Another possibility is default unsafe_raw filter code change, since it is executed on every execution.
To reporter, the backtrace would not help. Could you identify which module/SAPI trigger the assertion? and reproducible test script?
Do you only see this assertion error with FPM? i.e. Try cli server/apache/etc.
@rmoisto i'd definitely ask for a reproducer. Besides that, yet some questions
- what is the Opcache INI?
- are only core extensions used?
- could you check maybe more around the frame 4 about the class item
If anything from @yohgaki comment were possible, could be helpful too. At the current stage it smells to me like same as bug #74878.
This will only reproduce when MongoDB extension is enabled.
I'm writing new validation module, so I git pulled and merged current master to old branch for start. I found some silly mistakes which are my faults, but the code is messed by merge and broken. After I removed unneeded part and cleaned up the mess, it stopped raising this assertion error.
I made large change at once, so I cannot tell what kind of bad code would give this assertion error. Sorry.
(This might related to SAPI code. Filter module has input filtering hook for SAPI. This might be the cause)
@rmoisto were you up to check this one with the latest 7.2 RC? As bug #74878 was fixed, it's worth to check.
This did still reproduce with RC2 but seems to be fixed in RC4. Cannot reproduce anymore.
Thanks for checking :)