[2.0] Multiple entity managers + debug=false + env=dev fails

[igorw]

On the 2.0 branch, when using multiple entity managers and running a console command with --no-debug and --env=dev, I get:

[RuntimeException] Cannot dump definitions which have method calls.

Which originates from the Symfony\Component\DependencyInjection\Dumper\PhpDumper.

This only happens with the debug=false and env=dev combination.

FWIW, here's a stack trace:

array(11) {
  [0]=>
  array(5) {
    ["file"]=>
    string(117) "/project/vendor/symfony/src/Symfony/Component/DependencyInjection/Dumper/PhpDumper.php"
    ["line"]=>
    int(377)
    ["function"]=>
    string(9) "dumpValue"
    ["class"]=>
    string(54) "Symfony\Component\DependencyInjection\Dumper\PhpDumper"
    ["type"]=>
    string(2) "->"
  }
  [1]=>
  array(5) {
    ["file"]=>
    string(117) "/project/vendor/symfony/src/Symfony/Component/DependencyInjection/Dumper/PhpDumper.php"
    ["line"]=>
    int(538)
    ["function"]=>
    string(21) "addServiceMethodCalls"
    ["class"]=>
    string(54) "Symfony\Component\DependencyInjection\Dumper\PhpDumper"
    ["type"]=>
    string(2) "->"
  }
  [2]=>
  array(5) {
    ["file"]=>
    string(117) "/project/vendor/symfony/src/Symfony/Component/DependencyInjection/Dumper/PhpDumper.php"
    ["line"]=>
    int(596)
    ["function"]=>
    string(10) "addService"
    ["class"]=>
    string(54) "Symfony\Component\DependencyInjection\Dumper\PhpDumper"
    ["type"]=>
    string(2) "->"
  }
  [3]=>
  array(5) {
    ["file"]=>
    string(117) "/project/vendor/symfony/src/Symfony/Component/DependencyInjection/Dumper/PhpDumper.php"
    ["line"]=>
    int(93)
    ["function"]=>
    string(11) "addServices"
    ["class"]=>
    string(54) "Symfony\Component\DependencyInjection\Dumper\PhpDumper"
    ["type"]=>
    string(2) "->"
  }
  [4]=>
  array(5) {
    ["file"]=>
    string(63) "/project/app/bootstrap.php.cache"
    ["line"]=>
    int(877)
    ["function"]=>
    string(4) "dump"
    ["class"]=>
    string(54) "Symfony\Component\DependencyInjection\Dumper\PhpDumper"
    ["type"]=>
    string(2) "->"
  }
  [5]=>
  array(5) {
    ["file"]=>
    string(63) "/project/app/bootstrap.php.cache"
    ["line"]=>
    int(780)
    ["function"]=>
    string(13) "dumpContainer"
    ["class"]=>
    string(35) "Symfony\Component\HttpKernel\Kernel"
    ["type"]=>
    string(2) "->"
  }
  [6]=>
  array(5) {
    ["file"]=>
    string(63) "/project/app/bootstrap.php.cache"
    ["line"]=>
    int(513)
    ["function"]=>
    string(19) "initializeContainer"
    ["class"]=>
    string(35) "Symfony\Component\HttpKernel\Kernel"
    ["type"]=>
    string(2) "->"
  }
  [7]=>
  array(5) {
    ["file"]=>
    string(113) "/project/vendor/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php"
    ["line"]=>
    int(80)
    ["function"]=>
    string(4) "boot"
    ["class"]=>
    string(35) "Symfony\Component\HttpKernel\Kernel"
    ["type"]=>
    string(2) "->"
  }
  [8]=>
  array(5) {
    ["file"]=>
    string(113) "/project/vendor/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php"
    ["line"]=>
    int(66)
    ["function"]=>
    string(16) "registerCommands"
    ["class"]=>
    string(50) "Symfony\Bundle\FrameworkBundle\Console\Application"
    ["type"]=>
    string(2) "->"
  }
  [9]=>
  array(5) {
    ["file"]=>
    string(100) "/project/vendor/symfony/src/Symfony/Component/Console/Application.php"
    ["line"]=>
    int(118)
    ["function"]=>
    string(5) "doRun"
    ["class"]=>
    string(50) "Symfony\Bundle\FrameworkBundle\Console\Application"
    ["type"]=>
    string(2) "->"
  }
  [10]=>
  array(5) {
    ["file"]=>
    string(51) "/project/app/console"
    ["line"]=>
    int(22)
    ["function"]=>
    string(3) "run"
    ["class"]=>
    string(37) "Symfony\Component\Console\Application"
    ["type"]=>
    string(2) "->"
  }
}

Side note: When removing the additional entity managers (leaving just one default one), the container compiles. Re-adding them after that does not trigger re-compilation, so it just ignores the newly added entity managers.

[stof]

The 2.0 branch contains the subtree split of the symfony repo so please report issues to Symfony directly

[igorw]

Can you please make up your mind? The tickets I filed against symfony/symfony 2 weeks ago you asked me to re-file here.

[stof]

Well, here, you are saying it affects 2.0

[igorw]

So do the other tickets.

[stof]

could you give the link to the other ticket ? Browsing closed issues in the Symfony repo is not fun

[igorw]

• https://github.com/symfony/symfony/issues/3577
• https://github.com/symfony/symfony/issues/3578
• https://github.com/symfony/symfony/issues/3579

[stof]

3577 is about asking a new feature, so it is not about 2.0, meaning this issue tracker should have been used :) And 3579 was about Doctrine itself (and fixed)...

But the current issue is a bug affecting 2.0 (which seems related to the DI component btw according to the place where it fails) so it should indeed go to the symfony repo.

[igorw]

Does that mean you will re-open 3578?

[stof]

@schmittjoh could you look at it ? It looks more like an issue in the DI component than in DoctrineBundle

[alexandresalome]

I'm having this error message, but in different circonstances: test environment. Looks like it's a bundle from application making it crash.

When dumping service routing.loader, it crashes with same message as above (Cannot dump definitions which have method calls.).

I'm investigating

[alexandresalome]

Crazy thing...

This is a project where the session is disabled (stateless).

In config_test.yml this section was present:

framework:
    test: ~
    session:
        storage_id: session.storage.filesystem

I just removed the session section and now it works.

Don't get the relation with my bundle, but whatever.

Hope it helps

[pulse00]

i'm having the same error, however in my case it occurs if the following conditions are met:

• LiipImagineBundle is active
• profiler: { only_exceptions: false } is in the framework node of the config_dev.yml file

As soon as i either remove LiipImagineBundle or profiler: { only_exceptions: false }, the exception is gone.

[YetiCGN]

I am running into the same problem after upgrading to Symfony 2.0.15 from 2.0.9. Deactivating the profiler is not an option, because it greatly reduces debugging productivity. What can we do to mitigate this?

[stof]

I never managed to reproduce the issue and so I am unable to debug it. Please provide a minimal project reproducing it.

[YetiCGN]

I have worked around it by commenting line 994 in PhpDumper and replacing it with "return 'null';", which changes this method in appDevDebugProjectContainer.php (and possibly other generated files):

    protected function getTemplating_Helper_FormService()
    {
        return $this->services['templating.helper.form'] = new \Symfony\Bundle\FrameworkBundle\Templating\Helper\FormHelper(null, array(0 => 'FrameworkBundle:Form'));
    }

The first parameter null is where the workaround plays into. Since we do not use Forms in the project, it works for now.

I will compile a minimal test case for you.

[stof]

Closing this as the issue has been resolved: it is a broken implementation of ObjectStorage in PHP 5.4.0