Cache issue with NativeEncoder.php from tedivm

I’m running Concrete5 5.8.12 on a WIMP stack with PHP 7.4.33.

I’ve been plagued with intermittent (but quite frequent) EMERGENCY exceptions like:

[2023-08-17 11:59:01] exceptions.EMERGENCY: Exception Occurred: <my_path>\concrete5\concrete\vendor\tedivm\stash\src\Stash\Driver\FileSystem\NativeEncoder.php:25 include(): Failed opening '<my_path>/concrete5/application/files/cache/expensive\0fea6a13c52b4d47\25368f24b045ca84\38a865804f8fdcb6\57cd99682e939275\8f3a01e2e3b200aa\f980d8ea6abd2ae6\aa926918a6c91949\431e2245bd4ce662.php' for inclusion (include_path='<my_path>/concrete5/concrete/vendor;.;C:\php\pear') (2)  ["[object] (Whoops\\Exception\\ErrorException(code: 2): include(): Failed opening '<my_path>/concrete5/application/files/cache/expensive\\0fea6a13c52b4d47\\25368f24b045ca84\\38a865804f8fdcb6\\57cd99682e939275\\8f3a01e2e3b200aa\\f980d8ea6abd2ae6\\aa926918a6c91949\\431e2245bd4ce662.php' for inclusion (include_path='<my_path>/concrete5/concrete/vendor;.;C:\\php\\pear') at <my_path\\concrete5\\concrete\\vendor\\tedivm\\stash\\src\\Stash\\Driver\\FileSystem\\NativeEncoder.php:25)"] []

which cause the web server to respond with HTTP 500. I’m getting this on two different instances of Concrete5 and on two different Windows servers (2016 and 2022).

The PHP error log shows that most of these are causing a PHP Warning, but eventually they result in a PHP Fatal error. I think this might be leaving cgi/FastCGI processes in a busy and unrecyclable state which then eats up all my CPU and the web server essentially crashes.

I’ve not found much about this topic, but the nearest discussion I found was this:

So - the cache can get into a bit of a pickle with things being read and written simulaneously? The Issue sounds resolved from the point of view of C5 core, but maybe I’ve implemented the cache somewhere and am now running into the issue. Hmm. Any ideas, anyone?

The cache file in question:


exists and the application pool identity as Full Control.

Thanks for reading.
Chris Peckham

This patch has gone some what to improving my situation:

The commit is from Feb 10, 2021

I’ve not managed to reproduce the issue in a vanilla install of ConcreteCMS 8.5.12 but it is inherent in a couple of well-customized instances of the same version, so I suspect my use of the Expensive Cache is highlighting the issue here.


used to be


but the patch changes this to

try {
} catch (\Error $e) {
    return false;

The preceding lines test for the existence of this file, so it is surprising that the include can fail, but it does.

Does the existence test take into account file system permission to read?

I haven’t encountered the stash issue, but have seen similar where a file is created by a user other than the apache user. Sometimes with composer based installs run from an SSH CLI. Sometimes with FTP.

1 Like