Project

General

Profile

Actions

Bug #98124

open

potential dangerous destructor order

Added by Mordamir almost 2 years ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
System/Bootstrap/Configuration
Target version:
-
Start date:
2022-08-11
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
10
PHP Version:
7.4
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

TLDR: classSchemata property of ReflectionService is saved to data cache (extbase) inside the destructor the class. But the destructor of the used cache frontend is called before the destructor of ReflectionService. Currently this isn't a problem, because the standard cache frontends doesn't contain a destructor.

I'm currently writing an extension to collect live statistics of cache usage in typo3. For this i replace the standard frontends with other frontends which contains some counters. The counters must be persisted between two calls, so i write the data to database inside the destructor of my frontends. In the stored statistics i noticed there must be some missed cache writes. Some investigations showed this is related to how the reflection service stores his data to the cache. And i found out that the destructor of my replaced frontend class was called before the destructor of the reflection service. I'm not sure if my replaced frontends cause a change in the destructor order and if the destructor order would be the same on all installations using the same configuration.

As said earlier, currently this isn't causing problems in typo3, but it could if there would be a cache frontend which closes the connection to the cache backend in it's destructor.

Solution: The reflection service should write his cache data before the first destructor is called. Potential problem could be, if there is a class which uses the reflection service inside of its destructor.

No data to display

Actions

Also available in: Atom PDF