8000 Interface "DateTimeInterface" not found · Issue #8358 · php/php-src · GitHub
[go: up one dir, main page]
Skip to content

Interface "DateTimeInterface" not found #8358

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.

Sign up for GitHub

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

Jump to bottom
Closed
SCIF opened this issue Apr 13, 2022 · 18 comments
Closed

Interface "DateTimeInterface" not found #8358

SCIF opened this issue Apr 13, 2022 · 18 comments
Labels
Bug Status: Needs Triage

Comments

@SCIF
Copy link
SCIF commented Apr 13, 2022 •
edited
Loading

Description

composer.lock:

            "name": "nesbot/carbon",
            "version": "2.57.0",
            "source": {
                "type": "git",
                "url": "https://github.com/briannesbitt/Carbon.git",
                "reference": "4a54375c21eea4811dbd1149fe6b246517554e78"
            },

Sometimes I can see:
image

Obviously, there is an import. And yes, I double checked on the filesystem.

No idea how to reproduce. Looks like just one thread is buggy because the issue is intermittent. I experienced the same bug in prod (no XDebug comparing to my current setup) but that has fixed/doesn't fail anymore. These days it reproduces on local machine and I'm happy to help to debug/narrow down this therefore don't restart docker :).

A bit of info:

composer@php:/www/platform$ php -v
PHP 8.1.4 (cli) (built: Mar 18 2022 18:25:47) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.4, Copyright (c) Zend Technologies
    with Zend OPcache v8.1.4, Copyright (c), by Zend Technologies
    with Xdebug v3.1.3, Copyright (c) 2002-2022, by Derick Rethans

composer@php:/www/platform$ php -m
[PHP Modules]
bcmath
Core
ctype
curl
date
dom
fileinfo
filter
ftp
gmp
hash
iconv
igbinary
imagick
intl
json
libxml
mbstring
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_sqlite
Phar
posix
readline
redis
Reflection
session
SimpleXML
sodium
SPL
sqlite3
standard
tokenizer
xdebug
xml
xmlreader
xmlwriter
Zend OPcache
zip
zlib

[Zend Modules]
Xdebug
Zend OPcache

PHP Version

8.1.4

Operating System

Docker php:8.1-fpm-bullseye
@cmb69
Copy link
Member
cmb69 commented Apr 13, 2022

Does this also happen with OPcache disabled? If not, please try running OPcache without JIT, with function JIT and with tracing JIT. Would the issue happen then in all 3 cases?

@SCIF
Copy link
Author
SCIF commented Apr 13, 2022

Hi @cmb69 ,

Does this also happen with OPcache disabled?

I haven't tried. It's enabled on both prod and local.

If not, please try running OPcache without JIT, with function JIT and with tracing JIT. Would the issue happen then in all 3 cases?

I worry that issue will not be reproduced at all once I just restart the container. As I mentioned above, the same issue was happening on prod and that was temperamental, i.e. just restart of docker container helped to stop failures. Moreover not every deployment (starting containers with new version of images) caused such failures.

@arnaud-lb
Copy link
Member

Maybe related: #8164

@SCIF
Copy link
Author
SCIF commented Apr 15, 2022

Maybe related: #8164

Wow! #8164 is exactly the bug we experienced on prod I referred above.

@SCIF
Copy link
Author
SCIF commented Apr 15, 2022

I have dumped opcache_get_status() to a file as @arnaud-lb has advised in the linked issue. It's 650kb long. Do you want me to share with you? Any sensitive data there?

@arnaud-lb
Copy link
Member

Was it generated while the issue was happening ?

You can post it on gist.github.com or send it to my email. You may consider the filenames to be sensitive. You can redact them, but please let me know if the CarbonInterface.php file was listed in there.

@SCIF
Copy link
Author
SCIF commented Apr 16, 2022 •
edited
Loading

@arnaud-lb , yes, I added a dumping line on top of the index.php prior even framework bootstrap and clicked Refresh till it failed :)

1.log

I redacted a little bit to skip my project's files. Yes, CarbonInterface presents in the list.

One detail you could be interested in — the issue happened at 1650065374 but such last_used_timestamp exists only for index.php but not for CarbonInterface (however, I assume a lot of frameworks classes (ClassLoader, Container, etc) should be marked the same as well, so the timestamp could be useless).

@arnaud-lb
Copy link
Member

Thank you. Could you also share the opcache section of phpinfo() ? Are you using opcache.preload ? See also @cmb69's comment: knowing this would help to narrow the issue

@SCIF
Copy link
Author
SCIF commented Apr 17, 2022

@arnaud-lb , @cmb69 , here is an opcache section of ini_get_all():
opcache-ini.log

@arnaud-lb
Copy link
Member

Thank you @SCIF

For now I haven't succeeded in reproducing the issue locally.

If someone else wants to look at this, here is what I tried: https://github.com/arnaud-lb/issue-8358

@SCIF
Copy link
Author
SCIF commented Apr 17, 2022

Hi @arnaud-lb ,

Appreaciate your efforts! Just to clarify — the issue I experienced in prod in past was not caused by opcache_reset() (at least I couldn't find any invoke of opcache_reset() in vendor/ and nothing in app/ dir).

The way we deploy prod is next:

  1. application image is built on CI and pushed to a registry
  2. new images pulled and new containers started on a prod servers
  3. the entrypoint of image looks like:
php artisan config:clear && php artisan route:clear && php artisan view:cache
php artisan someappcache:validate-rewarm
exec php-fpm

@Levivb Levivb mentioned this issue Apr 21, 2022
Closed
@arnaud-lb arnaud-lb mentioned this issue Apr 22, 2022
Merged
@arnaud-lb
Copy link
Member

May be fixed by #8297

@cmb69
Copy link
Member
cmb69 commented Apr 22, 2022

@SCIF, could you please check this? Either build from source, or wait for PHP 8.1.6RC1 which is supposed to released on April, 28th.

@SCIF
Copy link
Author
SCIF commented Apr 22, 2022

@arnaud-lb , thanks for your work an proposed fix! Could you please respond a few questions related?

  1. Did you manage to reproduce the bug?
  2. Does the bug in Fix "Opcache breaks autoloading after E_COMPILE_ERROR" #8297 affect most likely one thread rather than all?
  3. Is there any way to prove that my failed php thread is buggy because of Fix "Opcache breaks autoloading after E_COMPILE_ERROR" #8297 by running some php code? (I didn't restart my container so it still fails every 5-7 requests). May be because of having fix for the bug, you could imagine what can lead to coredumping/whatever-else-specific-for-damaged-threads so this way we would prove the idea :)

@cmb69 , unfortunately, I don't meet this bug often. I mean, that's the very first time I experienced it locally. And based on past experience I met it in prod, just restart of container (even don't need to rebuild it) will «fix» the issue.

@arnaud-lb
Copy link
Member

I managed to produce a similar behavior (class not found caused by a leaked error), but I'm not sure that #8063 is the actual cause of this issue so I don't want to close it yet.

Does the bug in #8297 affect most likely one thread rather than all?

That's unlikely to affect only one thread.

Is there any way to prove that my failed php thread is buggy because of #8297 ?

If the issue disappears after an opcache_reset(), there is a chance it's related to that. Otherwise, probably not.

@SCIF
Copy link
Author
SCIF commented Apr 23, 2022

Hi @arnaud-lb ,

Thanks for the explanation!
I added opcache_reset(); at the very top of index.php and issue persists still :/

@SerafimArts
Copy link
Contributor

A similar problem occurs with functions. Now in production, with some periodicity, we catch errors of the lack of standard functions, like: Call to undefined function Monolog\Processor\memory_get_peak_usage().

So far, we are solving by restarting the docker container.

@Girgias
Copy link
Member
Girgias commented Jun 2, 2024

I am going to close this as it looks like a duplicate of #8164 which has been fixed.

If not, please open a new issue.

@Girgias Girgias closed this as not planned Won't fix, can't repro, duplicate, stale Jun 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug Status: Needs Triage
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@arnaud-lb @SCIF @cmb69 @SerafimArts @Girgias
0