Project

General

Profile

Actions

Bug #58969

closed

Call to a member function boot() on a non-object

Added by Oliver Eglseder almost 10 years ago. Updated almost 10 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
-
Target version:
-
Start date:
2014-05-20
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
5.5
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

CATEGORY: PackageManager/Cache

After deploying the project with TYPO3.Surf i can't open the Back- and Frontend. I get following error:

2014/05/20 17:14:11 [error] 23117#0: *3107 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Call to a member function boot() on a non-object in /data/www/<homepage>/shared/typo3cores/typo3_src-6.2.2/typo3/sysext/core/Classes/Package/PackageManager.php on line 151" while reading response header from upstream, [...]

i debugged the core to see what happens.
In PackageManager line 261

$this->packages = unserialize($packageObjects);

unserialize returns false, but does not throw E_NOTICE (as described on php.net, i enabled all error outputs)

i checked all permissions and filemodes, they are all set to user:group of nginx, i tried filemodes from 600 to 777 for all cache-files inside typo3temp/Cache/Code/cache_core
Deleting those Files does not change the behaviour. Clearing Caches in the Install tool doesn't either (sometimes it actually did, but i you can't rely on that). Only a accidental click on "Clear PHP opcode cache" made it working.

This lead to the idea to temporarily disable the zend extension and, i was surprised, it worked. flawless.

Now, since i can't disable opcache for the deployment, and the problem will keep showing up, i start questioning unserialize(), why does it return false but i don't E_NOTICE ? sorry, unsolved until yet, but why is there no check for successful unserialization? the result is just written into

 $this->activePackages 
for every marked "active" package in an other (cached) file, leading to an associative array of NULLs.

My suggestion would be:
if the return of unserialize() is false, clear opcache if available and rebuild the cached files in (at least) typo3temp/Cache/Code/cache_core. or just read the configuration vom the original file, as i would expect a system to behave when cached information is corrupt or unavailable.

I think this fix is important, because anyone with opcache enabled might suffer from this. (Suffer, because it's a frustrating error. took me more than a few days to finally discover the root cause)

Actions #1

Updated by Markus Klein almost 10 years ago

Did you clear the opcode cache after the deployment?
There's even an Install Tool button for this.

We can't capture all possible problems these various opcode caches may cause.
Some had to restart the web server after upgrading from 4.7 to 6.2 after changing the symlink, because the cache didn't realize this change and still loaded some old classes (partially).
There's no way for the Core to actually clear the cache, if there isn't even the correct code running.

Nevertheless I agree that the return value should be checked here.
But I'd suggest to check the return value of the cache->get().

// Strip off PHP Tags from Php Cache Frontend
$packageObjects = substr(substr($this->coreCache->get($packageCache['packageObjectsCacheEntryIdentifier']), 6), 0, -2);
$this->packages = unserialize($packageObjects);
Actions #2

Updated by Oliver Eglseder almost 10 years ago

I've written a Task that calls

\TYPO3\CMS\Core\Utility\OpcodeCacheUtility::clearAllActive();

like the Install Tool does. It is executed in the cleanup Stage (the last one, after symlink release). Unfortunately the Server Admin has disabled opcache for all Servers, so i can't replicate the situation.

Anyway, i'm still getting exceptions, but they are related to normal caching. I thin k i'll just write some more Tasks.

Invalid argument supplied for foreach() [...] ExtDirectApi.php line 122
No template has been specified. Use either setTemplateSource() or setTemplatePathAndFilename()

BTW: the string in $packageObjects was correct, i compared the file and the output while opcache was active. the real problem is unserialize()

Actions #3

Updated by Markus Klein almost 10 years ago

  • Status changed from New to Needs Feedback

Ok that is really weird. ;-)

Shall I close this issue then?

Actions #4

Updated by Oliver Eglseder almost 10 years ago

Yes, you can ;)

Actions #5

Updated by Markus Klein almost 10 years ago

  • Status changed from Needs Feedback to Closed
Actions

Also available in: Atom PDF