Bug #46424: Infinite recursive call in DependencyProxy - TYPO3.Flow - TYPO3 Forge

Bug #46424

Infinite recursive call in DependencyProxy

Added by Adrian Föder over 8 years ago. Updated about 8 years ago.

Status:

Resolved

Priority:

Must have

Assignee:

Robert Lemke

Category:

Object

Target version:

Start date:

2013-03-19

Due date:

% Done:

100%

Estimated time:

PHP Version:

Has patch:

Complexity:

Description

I have the following situation,

[19-Mar-2013 09:02:22 UTC] PHP Fatal error:  Maximum function nesting level of '500' reached, aborting! in ...\TYPO3.Flow\Classes\TYPO3\Flow\Object\ObjectManager.php on line 160
[19-Mar-2013 09:02:22 UTC] PHP Stack trace:
[19-Mar-2013 09:02:22 UTC] PHP   1. {main}() C:\Users\afoeder\PhpstormProjects\acme\Distribution\Web\index.php:0
[19-Mar-2013 09:02:22 UTC] PHP   2. TYPO3\Flow\Core\Bootstrap->run() C:\Users\afoeder\PhpstormProjects\acme\Distribution\Web\index.php:27
[19-Mar-2013 09:02:22 UTC] PHP   3. TYPO3\Flow\Http\RequestHandler->handleRequest() ...\TYPO3.Flow\Classes\TYPO3\Flow\Core\Bootstrap.php:113
[19-Mar-2013 09:02:22 UTC] PHP   4. TYPO3\Flow\Object\DependencyInjection\DependencyProxy->setRequest() ...\TYPO3.Flow\Classes\TYPO3\Flow\Http\RequestHandler.php:122
[19-Mar-2013 09:02:22 UTC] PHP   5. TYPO3\Flow\Object\DependencyInjection\DependencyProxy->__call() ...\TYPO3.Flow\Classes\TYPO3\Flow\Http\RequestHandler.php:122
[19-Mar-2013 09:02:22 UTC] PHP   6. call_user_func_array() ...\TYPO3.Flow\Classes\TYPO3\Flow\Object\DependencyInjection\DependencyProxy.php:96
[19-Mar-2013 09:02:22 UTC] PHP   7. TYPO3\Flow\Object\DependencyInjection\DependencyProxy->__call() ...\TYPO3.Flow\Classes\TYPO3\Flow\Object\DependencyInjection\DependencyProxy.php:0
[19-Mar-2013 09:02:22 UTC] PHP   8. call_user_func_array() ...\TYPO3.Flow\Classes\TYPO3\Flow\Object\DependencyInjection\DependencyProxy.php:96
[19-Mar-2013 09:02:22 UTC] PHP   9. TYPO3\Flow\Object\DependencyInjection\DependencyProxy->__call() ...\TYPO3.Flow\Classes\TYPO3\Flow\Object\DependencyInjection\DependencyProxy.php:0
[19-Mar-2013 09:02:22 UTC] PHP  10. call_user_func_array() ...\TYPO3.Flow\Classes\TYPO3\Flow\Object\DependencyInjection\DependencyProxy.php:96
[19-Mar-2013 09:02:22 UTC] PHP  11. TYPO3\Flow\Object\DependencyInjection\DependencyProxy->__call() ...\TYPO3.Flow\Classes\TYPO3\Flow\Object\DependencyInjection\DependencyProxy.php:0
.
.
.
.
[19-Mar-2013 09:02:23 UTC] PHP 492. call_user_func_array() ...\TYPO3.Flow\Classes\TYPO3\Flow\Object\DependencyInjection\DependencyProxy.php:96
[19-Mar-2013 09:02:23 UTC] PHP 493. TYPO3\Flow\Object\DependencyInjection\DependencyProxy->__call() ...\TYPO3.Flow\Classes\TYPO3\Flow\Object\DependencyInjection\DependencyProxy.php:0
[19-Mar-2013 09:02:23 UTC] PHP 494. call_user_func_array() ...\TYPO3.Flow\Classes\TYPO3\Flow\Object\DependencyInjection\DependencyProxy.php:96
[19-Mar-2013 09:02:23 UTC] PHP 495. TYPO3\Flow\Object\DependencyInjection\DependencyProxy->__call() ...\TYPO3.Flow\Classes\TYPO3\Flow\Object\DependencyInjection\DependencyProxy.php:0
[19-Mar-2013 09:02:23 UTC] PHP 496. TYPO3\Flow\Object\DependencyInjection\DependencyProxy->_activateDependency() ...\TYPO3.Flow\Classes\TYPO3\Flow\Object\DependencyInjection\DependencyProxy.php:95
[19-Mar-2013 09:02:23 UTC] PHP 497. Closure->__invoke() ...\TYPO3.Flow\Classes\TYPO3\Flow\Object\DependencyInjection\DependencyProxy.php:58
[19-Mar-2013 09:02:23 UTC] PHP 498. TYPO3\Flow\Security\Aspect\PersistenceQueryRewritingAspect->TYPO3\Flow\Security\Aspect\{closure}() ...\TYPO3.Flow\Classes\TYPO3\Flow\Object\DependencyInjection\DependencyProxy.php:58
[19-Mar-2013 09:02:23 UTC] PHP 499. TYPO3\Flow\Object\ObjectManager->get() C:\Users\afoeder\PhpstormProjects\acme\Distribution\Data\Temporary\Development\Cache\Code\Flow_Object_Classes\TYPO3_Flow_Security_Aspect_PersistenceQueryRewritingAspect.php:603

When debugging the DependencyProxy's __call() method, it turns out that it happens on TYPO3\Flow\Security\Context's setRequest method.

It looks like this especially happens when I become logged out on a "protected" page, maybe because of session timeout or such.

Files

500_Internal_Server_Error.pdf (58 KB) 500_Internal_Server_Error.pdf

Adrian Föder, 2013-03-27 12:32

Related issues

Updated by Robert Lemke over 8 years ago

Status changed from New to Accepted
Assignee set to Robert Lemke

Updated by Adrian Föder about 8 years ago

ah ok that's pretty straight-forward: the problem occurs very early,


4 TYPO3\Flow\Object\DependencyInjection\DependencyProxy::__call("setRequest", array|1|)
3 TYPO3\Flow\Object\DependencyInjection\DependencyProxy::setRequest(TYPO3\Flow\Mvc\ActionRequest)
2 TYPO3\Flow\Http\RequestHandler::handleRequest()
1 TYPO3\Flow\Core\Bootstrap::run()

So actually, it happens in \TYPO3\Flow\Http\RequestHandler::handleRequest, line 122:

$this->securityContext->setRequest($actionRequest);

This securityContext property is the DependencyProxy; however, it looks like the "realDependency" is again the DependencyProxy (maybe that even should be blocked with an exception, again).

Just in order to emphasize, this exception is thrown in my case:

    public function _activateDependency() {
        $realDependency = $this->builder->__invoke();
        if ($realDependency instanceof $this) {
            throw new \Exception('The actual dependecy which should be proxies by the Dependency Proxy is again the Dependency Proxy which must never occur.');
        }

Updated by Adrian Föder about 8 years ago

("split" this topic to an additional one, #46716)

Updated by Adrian Föder about 8 years ago

File 500_Internal_Server_Error.pdf 500_Internal_Server_Error.pdf added

I debugged the invocations of ObjectManager->get(...Security\Context), and,

the first invocation instantiated and returned the correct class
the second one returned the correct object from the $this->objects stack
the third invocation also returned from the $this->objects stack, but the dependency proxy!

So, the whole HTTP request handling thing already only get the (incorrect) DependencyProxy object; means,
\TYPO3\Flow\Http\RequestHandler::resolveDependencies and \TYPO3\Flow\Http\RequestHandler::handleRequest all has only the DependencyProxy (see Note 2 here).

The last ObjectManager->get(...Security\Context) invocation which returns the correct SecurityContext is one related to AspectQueryRewriting, Content Security etc...
See attached file for a backtrace (I made a dummy exception).