Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Prevent infinite nesting of lazy ObjectManager instances when ObjectManager is reset #44399

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

Ocramius
Copy link
Contributor

@Ocramius Ocramius commented Dec 1, 2021

Q A
Branch? 4.4
Bug fix? yes
New feature? no
Deprecations? no
Tickets
License MIT
Doc PR

This patch ensures that the ObjectManager that the Symfony\Bridge\Doctrine\ManagerRegistry
replaces during Symfony\Bridge\Doctrine\ManagerRegistry#resetService() operations is a fresh
non-lazy service.

Before this change, Symfony\Bridge\Doctrine\ManagerRegistry#resetService() would replace the
initialization of the lazy proxy with a new service each time, but that service being lazy, this
led to an additional proxy nesting level at each service reset call. That leads to general
issues around memory reliability, stack trace nesting (and therefore bigger logged traces) and
potentially even stack overflow problems, when running with XDebug.

The problem seems to only apply when the symfony/dependency-injection Container is compiled
as a set of small factory files: that's because each generated factory has a boolean flag that
indicates whether a lazy or non-lazy version of a service is requested, as introduced in the
original implementation at #7890

…ctManager` is reset

This patch ensures that the `ObjectManager` that the `Symfony\Bridge\Doctrine\ManagerRegistry`
replaces during `Symfony\Bridge\Doctrine\ManagerRegistry#resetService()` operations is a fresh
non-lazy service.

Before this change, `Symfony\Bridge\Doctrine\ManagerRegistry#resetService()` would replace the
initialization of the lazy proxy with a new service each time, but that service being lazy, this
led to an additional proxy nesting level at each service reset call. That leads to general
issues around memory reliability, stack trace nesting (and therefore bigger logged traces) and
potentially even stack overflow problems, when running with XDebug.

The problem seems to only apply when the `symfony/dependency-injection` `Container` is compiled
as a set of small factory files: that's because each generated factory has a boolean flag that
indicates whether a lazy or non-lazy version of a service is requested, as introduced in the
original implementation at symfony#7890
@Ocramius Ocramius force-pushed the fix/prevent-infinite-proxy-nesting-in-lazy-entitymanager branch from 15d6e01 to 770425c Compare December 1, 2021 16:29
@nicolas-grekas
Copy link
Member

Good catch, thanks @Ocramius.

@nicolas-grekas nicolas-grekas merged commit e9acd68 into symfony:4.4 Dec 2, 2021
@Ocramius Ocramius deleted the fix/prevent-infinite-proxy-nesting-in-lazy-entitymanager branch December 3, 2021 06:08
This was referenced Dec 9, 2021
This was referenced Dec 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants