The dependency checker is fine: only the constructor's arguments should be considered as any other kind of circular loop is solvable. There are many test cases that prove it already.

About this specific loop that happens at runtime would you be able to provide a reproducing test case in PhpDumperTest::testAlmostCircular()? (see https://github.com/symfony/symfony/blob/master/src/Symfony/Component/DependencyInjection/Tests/Fixtures/containers/container_almost_circular.php for examples)

About the doc PR, please do of course!

@nicolas-grekas I've been working on this issue this morning and I need some help to create the reproducer: why are variables like $a or $b defined like ($this->services['validator'] ?? $this->getValidatorService()); while others like $c or $f are instanciated right in the method getDoctrine_Dbal_DefaultConnectionService()

From what I understand from https://github.com/symfony/symfony/blob/master/src/Symfony/Component/DependencyInjection/Tests/Fixtures/containers/container_almost_circular.php, it is only used for services (like $a or $b). Do you have another example for instances like $c or $f please?

The closer code to the current issue in src/Symfony/Component/DependencyInjection/Tests/Fixtures/php/services_almost_circular_public.php is:

    /**
     * Gets the public 'foo2' shared service.
     *
     * @return \FooCircular
     */
    protected function getFoo2Service()
    {
        $a = new \BarCircular();

        $this->services['foo2'] = $instance = new \FooCircular($a);

        $a->addFoobar(($this->services['foobar2'] ?? $this->getFoobar2Service()));

        return $instance;
    }

But the service is defined in $this->services before any method is called on the service's dependencies ($a->addFoobar() in the previous code) which solves the issue.

=> In my bug's code, the methods are called before the instantiation of the service, and the instantiation is done on the return line: how may I reproduce this behavior?

@nicolas-grekas actually, we used to have such protections against more complex circular references in Symfony 3.2 and older, where all internals service references were using $this->get() as well.
We still have the code for that in Container::get in newer versions (even in 5.0), but it is not effective anymore, because we are now bypassing the layer checking and updating $this->loading.

All related issues arise when services are inlined. To prevent a service from being inlined, the reproducer should use public services. I'd recommend trying to reproduce the graph you have at hand using dummy services: all services that are dumped as methods should be public, all the others private.

Then, why the variables are dumped this way is complex, I cannot give you a simple answer.

@stof adding the check would not solve anything I fear. It might actually break solvable graphs as sometimes there need to be two calls to a service factory to create the fully configured service (there are tests doing so already).

In the end, either the circular loop is legit and should be detected at compile time - but to my current understanding, as soon as a loop involves a setter or a property, it should not turn into a runtime loop but can be solved instead, by creating the services (especially the inlined ones) in the correct order.

A way to see this is: how would I instantiate this graph if I were to create the code by hand? If there is a solution to this that is not found currently, that's the bug.

@nicolas-grekas there is also another issue: the dumper assumes that any lazy reference won't trigger a circular reference. But that is a valid assumption only as long as they are not resolved during the instantiation.

I see in the dumped code that some of the calls to instantiate inline services are followed by a check whether the requested service is now instantiated (due to some circular reference). I think that the safe logic would be to have such check after all method calls. Or at least after any such method call that involves a soft reference to the current service (i.e. including lazy references, references through method calls, and potential references through injecting the service_container service) in the object graph of the service on which we call the method (in case of method calls) or that we instantiate (in case of instantiation of a different service).

It might actually break solvable graphs as sometimes there need to be two calls to a service factory to create the fully configured service (there are tests doing so already).

That is actually the root of the bug, not a feature. If we call the factory twice, we will have 2 different instances of the service in different parts of the object graph if assignments to $this->services (or $this->privates) are not done in the right place. And if assignments are done properly, the second call should not happen, as it will use the existing instance.

The big benefit of these runtime checks is that you have a (more or less) clear exception message here, rather than having a broken object graph (like having 2 different instances of your entity manager in different parts of the project). And you know that you have an issue in your service instantiation.

I think I've grown gray hairs from this issue so I would be very happy if anyone else could take over and do the improvements :)

btw, re-adding these loading checks as safeguards will not be easy. We could add such $this->loading checks in the dumped code of factories. But things will become much harder in places where we inline the factories.

I've just bumped into the exact same problem, circular dep via doctrine subscriber and serializer led to segfault, running with xdebug showed a proper trace to track this down.

The interesting bit was that it only showed up when I tried to install symfony/proxy-manager-bridge.

I never looked into the internals of DI, so can't really contribute here, just making this comment in case it will be useful for somebody.

I solved it by replacing the doctrine subscriber with an entity listener.

does #39799 fix your issue ?