Maravel-Framework 10.61.0 prevents circular dependency

#dependencyinjection #maravelframework #circulardependencies #maravelith

Maravel-Framework 10.61.0

There were multiple attempts to add this feature in Laravel like:

Because the macroable classes are resolved from the container in Maravel-Framework, there are some corner cases like \Illuminate\Events\Dispatcher or Illuminate\Console\Scheduling\Schedule which if resolved from container would generate circular dependency that leads to segmentation fault or memory exhaustion.

This can happen also to developers leading to long debug time.

To shorten the detection of such cases , this PR introduces a hard limit of 10 MB by default, configurable via app.circular_dependency_memory_limit:

    /**
     * Limit of extra memory used to detect circular dependencies when resolving an abstract from container (bytes)
     */
    'circular_dependency_memory_limit' => 10485760,

The error it generates:

Illuminate\Contracts\Container\CircularDependencyException

Circular dependency detected while resolving [Illuminate\Console\Scheduling\Schedule]. Memory limit reached or exceeded 10485760 bytes. Dependencies initial memory (bytes):{“Illuminate\Console\Scheduling\Schedule”:27262976}

at vendor/macropay-solutions/maravel-framework/illuminate/Container/Container.php:886

This translates to:

When Illuminate\Console\Scheduling\Schedule starts to be resolved from container, the memory used by PHP, read via*\memory_get_usage(true),* was 27262976 bytes. Then the code went in an infinite loop until the memory difference exceeded 10 MB ( 10485760 bytes ), meaning the memory used by PHP was greater or equal to 27262976 + 10485760 bytes. If not stopped, this would continue until a segmentation fault would trigger a hard to debug memory exhausted fatal error.

Notes:

The limit based on time gives segmentation fault/memory limit fatal.

My first try to limit based on increments is not reliable as it can be seen here.

This is a second improvement after the di helper that does not call make on the container if it did not finish booting.

Top comments (1)

Sahith kumar Singari • Feb 6

Great improvement 👍

Using a memory-based guard to detect circular dependencies is a very pragmatic solution, especially given how late these cases surface in PHP (segfault / OOM instead of a clean exception).

I like that this:

avoids relying on time-based limits, which are nondeterministic
fails fast with a clear CircularDependencyException
protects against hard-to-debug issues in macro-resolved classes like Dispatcher and Schedule

The explanation of tracking memory_get_usage(true) deltas makes the trade-off very clear.
Having app.circular_dependency_memory_limit configurable is also a nice touch for edge cases or constrained environments.

Overall, this feels like a practical safety net rather than a theoretical purity fix — exactly what a DI container in PHP needs. 👏