Proxy's `__debugInfo()` must not have side effects

[flack]

Bug Report

Q	A
BC Break	yes/no
Version	2.12.3

Summary

I'm using Entity classes which have the magic __debugInfo() method defined. When I try to load a reference to a nonexistant Entity and var_dump it with the following code:

$proxy = $em->getReference($my_classname, $this_id_does_not_exist);
var_dump($proxy);

the program dies

Current behavior

I get the following error (edited for readability):

PHP Warning:  Uncaught Doctrine\ORM\EntityNotFoundException: Entity of type 'my_class' for IDs id(1) was not found in vendor/doctrine/orm/lib/Doctrine/ORM/EntityNotFoundException.php:33
Stack trace:
#0 vendor/doctrine/orm/lib/Doctrine/ORM/Proxy/ProxyFactory.php(139): Doctrine\ORM\EntityNotFoundException::fromClassNameAndIdentifier()
doctrine/orm#1 /tmp/cache/__CG__my_class.php(224): Doctrine\ORM\Proxy\ProxyFactory->Doctrine\ORM\Proxy\{closure}()
doctrine/orm#2 /tmp/cache/__CG__my_class.php(224): Closure->__invoke()
doctrine/orm#3 [internal function]: DoctrineProxies\__CG__\my_class->__debugInfo()
doctrine/orm#4 testscript.php(2): var_dump()
doctrine/orm#5 {main}
  thrown in vendor/doctrine/orm/lib/Doctrine/ORM/EntityNotFoundException.php on line 33
PHP Fatal error:  __debuginfo() must return an array in test.php on line 2
PHP Stack trace:
PHP  1. test() testscript.php:1
PHP  2. var_dump($value = class DoctrineProxies\__CG__\my_class { /*...*/ public $__initializer__ = class Closure { virtual $closure = "$this->Doctrine\ORM\Proxy\{closure}",  }; public $__cloner__ = class Closure { virtual $closure = "$this->Doctrine\ORM\Proxy\{closure}",  }; public $__isInitialized__ = FALSE }) testscript.php:2
PHP Fatal error:  __debuginfo() must return an array in testscript.php on line 2
PHP Stack trace:
PHP  1. test() testscript.php:1
PHP  2. var_dump($value = class DoctrineProxies\__CG__\my_class { /*...*/ public $__initializer__ = class Closure { virtual $closure = "$this->Doctrine\ORM\Proxy\{closure}",  }; public $__cloner__ = class Closure { virtual $closure = "$this->Doctrine\ORM\Proxy\{closure}",  }; public $__isInitialized__ = FALSE }) testscript.php:2

How to reproduce

You need PHP 8 or greater and Xdebug loaded. Without xdebug, it works, and with xdebug it works in PHP 7.4 and below. I can try to make some minimal reproduction if it's necessary, for a quick reproduction, you can run the tests of https://github.com/flack/midgard-portable. The result will look like here: https://scrutinizer-ci.com/g/flack/midgard-portable/inspections/464a6111-e297-4cbb-9637-e90870531345

Expected behavior

It should work like it does in PHP 7.x

[flack]

P.S.: Wrapping getReference() and var_dump in a try/catch block doesn't help. Just in case someone wants to suggest that :-)

[derrabus]

Shouldn't this be reported to Xdebug instead?

[flack]

Yeah, maybe. I originally did not find a way to reproduce it without the Doctrine proxy involved, but I just found that this also triggers it:

class test
{
    public function __debugInfo()
    {
        throw new Exception('X');
        return [];
    }
}

var_dump(new test);

So the problem is that Doctrine throws here:

https://github.com/doctrine/orm/blob/b9f2488c6c08c89c329e0643f146e974c099e075/lib/Doctrine/ORM/Proxy/ProxyFactory.php#L137-L140

There is only one thing I don't understand, and that is where var_dump gets called in the first place. I just made the example above because it was the shortest way to reproduce, but in the actual code where I found the problem, there are no calls to var_dump, not even in the vendor tree. The error occurs in this code block:

https://github.com/flack/midgard-portable/blob/cfa49efefecb943d55602ed158c49572837032d3/test/api/mgdobjectTest.php#L88-L92

If I comment out either of those two lines, the problem disappears. Digging a bit deeper, I noticed that if I change the code in ProxyFactory to look like this:

try {
    throw EntityNotFoundException::fromClassNameAndIdentifier(
        $classMetadata->getName(),
        $this->identifierFlattener->flattenIdentifier($classMetadata, $identifier)
    );
} catch (EntityNotFoundException $e) {
    die('Caught');
}

The exception does not get caught. I'm not sure, but it kind of seems like there's something funky going on on the doctrine side, too.

Anyway, I also opened https://bugs.xdebug.org/view.php?id=2100 on the xdebug side

[flack]

after some more research, I'm pretty sure now that this is really only an xdebug issue, closing this one.

[derrabus]

Thanks!

[flack]

Short update: I've since discovered php/php-src#7922 which states that the Fatal Error mentioned above is actually a current core PHP behavior/bug. The __debugInfo() method generated in doctrine proxies looks like this:

    /**
     * {@inheritDoc}
     */
    public function __debugInfo()
    {

        $this->__initializer__ && $this->__initializer__->__invoke($this, '__debugInfo', []);

        return parent::__debugInfo();
    }

and $this->__initializer__->__invoke($this, '__debugInfo', []); can throw, as shown above. So I would argue that it is currently not really safe to implement __debugInfo() on your Entity classes (at least when using proxies), because they might randomly crash your program.

So I wonder: would it make sense to open a new feature request or similar to add a try/catch around the __invoke call in the generated method? Because at least currently, throwing from __debugInfo simply seems unsupported in PHP.

[derrabus]

Makes sense to me.

[derickr]

I can't really fix this on the @xdebug side, as it expects (quite reasonably) that __debugInfo() can be called without any side-effects. If Doctrine has side effects here (including, but not exclusively, throwing Exceptions), then this needs fixing in Doctrine.

[flack]

changed the title to reflect the latest findings

[beberlei]

We should catch the exception and return a debug info including the exception message. This must be in doctrine/common ProxyGenerator