-
Notifications
You must be signed in to change notification settings - Fork 7.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crashes in zend_accel_inheritance_cache_find since upgrading to 8.1.3 due to corrupt on-disk file cache #8143
Comments
Disabling the PHP opcache file_cache by commenting out the line
seems to avoid the issue. |
That's somewhat unlikely, since that commit only changed some version numbers (it can be tricky to use |
Correct, but it's reproducible. I'm also puzzled by that. I was wondering if the build system uses different flags when built with a -dev version? |
Ah, a -dev version produces a different zend_system_id, so that uses different OPcache SHM and file cache. Anyhow, please provide a stack backtrace. :) |
|
Thanks for the stack backtrace! According to that and the PHP version, the segfault occurs on this line: php-src/ext/opcache/ZendAccelerator.c Line 2252 in 9bc17e4
Can you please confirm? If so, that hints at a memory corruption, since |
Indeed! I have no idea, though, where that might have happened. |
I did one more experiment: I recompiled 8.1.3 with the following patch
No crash happening with this change. |
I found a directory C:\Windows\Temp\a988dea0ccab6bc2fc34dfff91a65bb9 containing a lot of subdirectories. Each of those dirs contained lots of *.bin files. That said, this still smells like a bug. I don't think the php file opcache should get confused like this and trigger such a memory corruption. |
These folders are the file_cache. There are separate file caches for different PHP versions (and different users, SAPIs, etc.) Obviously, at least one of these caches has been corrupted causing the segfault. And yes, that would be a bug, but it's hard to figure out what is wrong exactly. |
I'm researching a similar bug I'm seeing in another program. We see similar crashes on computers that run Symantec Endpoint Protection. Do you have Symantec Endpoint Protection installed? |
We don't have Symantec Endpoint Protection installed. |
Thanks for the fast reply. Then it is not the type of fault I'm trying to track. |
This also occurs on CentOS Linux release 7.9.2009 (Core)
|
@cristicotet, please try without Xdebug. |
It works fine after disabling xdebug. |
Running with and without Xdebug is supposed to use two distinct file caches. |
It happened again with xdebug disabled:
strace
|
One more finding how I managed to corrupt the cache: |
For version 8.1.6 it happens a lot more often and it doesn't go away if I clear opcache
|
We also experience crashes due to segmentation fault in Execution environmentWe use php-fpm with opcache and opcache filecache. This bug happens erratically (and thus is very difficult to reproduce) when we deploy a new code release using the following scheme: we pre-warm opcache by referencing files in a new code release (which creates opcache filecache entries), and then we switch current revision symlink to a new release and do php-fpm reload (that is opcache is populated from filecache).
|
We also switch to new releases by updating a symlink, maybe this confuses opcache. After updating symlink we call opcache_clear() by making an curl api call (to make sure that opcache_clear() is called in the correct context: nginx + php-fpm). From what I remember, the crash is not happening immediately after deploying new version but much later (even days later). Currently at version 8.1.12, it happens less often than 8.1.6 (don't know exactly when it started to happen less often). |
I ran into what seems to be this while upgrading between Debian-compatible builds of 8.1.15 provided by the Sury repository. Clearing out the file cache fixed the segmentation fault, which seems to have arisen on the 'entry->parent` line mentioned. |
Here are the steps to reproduce that work for my php-fpm:
My PHP version:
Backtrace:
Strace of failing worker:
|
This should be fixed via 90f2e76 |
Description
I dont't have a minimal reproducer for this but an application which is based on sabre/dav running on Windows Server 2016 using IIS
Since upgrading from 8.1.2 to 8.1.3 I get frequent 500 errors.
In the event log I find
The relevant opcache configuration from php.ini:
I ran a git bisect since 8.1.2 was working fine.
The first faulty commit is 78fd573
Attaching a debugger to a running php-cgi.exe process, I see
PHP Version
PHP 8.1.3
Operating System
Windows Server 2016 / IIS
The text was updated successfully, but these errors were encountered: