Skip to content
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

[Behat]Cannot run full tests suites with symfony 4.4 #34687

Closed
michaoj opened this issue Nov 28, 2019 · 15 comments
Closed

[Behat]Cannot run full tests suites with symfony 4.4 #34687

michaoj opened this issue Nov 28, 2019 · 15 comments

Comments

@michaoj
Copy link

michaoj commented Nov 28, 2019

Symfony version(s) affected: 4.4.0

Description
When I run my behat tests, I end up getting a Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 32768 bytes) in /var/www/project/var/cache/test/pools/AqNbLoad6z/E/7/9TL8Zv8iSmZZttWPui9Q on line 1 after several scenarii

How to reproduce
This occurs every time I try to run the full behat tests suite

Possible Solution
Maybe a container reload issue ?

Additional context

  • This worked flawlessly with symfony version 4.3.x
  • I use the symfony/http-kernel 4.4.x-dev
  • I updated my Kernel with $container->setParameter('container.dumper.inline_factories', true);
@nicolas-grekas
Copy link
Member

nicolas-grekas commented Nov 28, 2019

Likely fixed by #34580

@michaoj
Copy link
Author

michaoj commented Nov 28, 2019

@nicolas-grekas : I guess you mean #34567 ?

@michaoj
Copy link
Author

michaoj commented Nov 28, 2019

I checked my file vendor/symfony/http-kernel/Kernel.php

And here's the content for the line 517 has mentionned in #34580 change log

if (file_exists($cachePath) && \is_object($this->container = include $cachePath)
            && (!$this->debug || (self::$freshCache[$cachePath] ?? $cache->isFresh()))
        ) {
            self::$freshCache[$cachePath] = true;
            $this->container->set('kernel', $this);
            error_reporting($errorLevel);

            return;
        }

I still have the memory error

@adrienfr
Copy link
Contributor

Same here since SF 4.4, Behat tests seems to use a lot more memory and full tests suite fails on CircleCI with error Received 'killed' signal at random scenario.

@michaoj
Copy link
Author

michaoj commented Nov 28, 2019

Same here since SF 4.4, Behat tests seems to use a lot more memory and full tests suite fails on CircleCI with error Received 'killed' signal at random scenario.

Thought I was alone 😄

@nicolas-grekas
Copy link
Member

Reproducer and/or Blackfire profile welcome. Otherwise it's going to be yours to debug.

@michaoj
Copy link
Author

michaoj commented Nov 28, 2019

I profile two calls of a subset of my behat tests
https://blackfire.io/profiles/551c95b2-2f40-405e-a0d8-ab7e2a085c45/graph
And
https://blackfire.io/profiles/09125477-3b93-4b28-8e25-34fa1cba4d22/graph

If I try to combine the two tags, I'm unable to profile with an out of memory error
image

@xabbuh
Copy link
Member

xabbuh commented Nov 29, 2019

Can you profile the same but with Symfony 4.3 and share the profile comparison?

@nicolas-grekas
Copy link
Member

I updated my Kernel with $container->setParameter('container.dumper.inline_factories', true);

I did not understand this part: does setting this to true fix the issue? or setting it to false maybe?

@michaoj
Copy link
Author

michaoj commented Nov 29, 2019

I updated my Kernel with $container->setParameter('container.dumper.inline_factories', true);

I did not understand this part: does setting this to true fix the issue? or setting it to false maybe?

No setting this to true doesn't fix the problem, and without it it doesn't work either

@michaoj
Copy link
Author

michaoj commented Nov 29, 2019

Can you profile the same but with Symfony 4.3 and share the profile comparison?

I'm trying : with sf 4.3 the full behat tests suite run

But running the same profiling than yesterday brings me a
image

@adrienfr
Copy link
Contributor

adrienfr commented Dec 3, 2019

I tried again with SF 4.4.1 (since #34580 has been merged) and still have the issue on CircleCI, it fails 90% of the time with the Received 'killed' signal error.

SF 4.3.8

265 scenarios (264 passed, 1 failed)
3811 steps (3642 passed, 1 failed, 168 skipped)
27m13.66s (301.51Mb)

SF 4.4.1

265 scenarios (264 passed, 1 failed)
3811 steps (3642 passed, 1 failed, 168 skipped)
26m10.73s (2.44Gb)

As I don't have this issue on my local env but only on CircleCI (not the same memory amount available), I don't have a blackfire profile to share... Is there any other way to help you investigate this (other than setup blackfire on CircleCI) ?

Thanks

@nicolas-grekas
Copy link
Member

Providing a small app we could run locally to reproduce the issue would be the best help!

@adrienfr
Copy link
Contributor

adrienfr commented Dec 4, 2019

@michaoj, do you use Panther (Symfony\Component\Panther\PantherTestCase) or another tool using BrowserKit ?

The issue might come from this, as I don't have any issue with pure PHPUnit using Symfony\Bundle\FrameworkBundle\Test\WebTestCase :

4.3.9

PHPUnit: Time: 6.96 minutes, Memory: 1.11 GB
Behat: 27m13.66s (301.51Mb)

4.4.1

PHPUnit: Time: 6.41 minutes, Memory: 1.16 GB
Behat: 26m10.73s (2.44Gb)

@michaoj
Copy link
Author

michaoj commented Dec 5, 2019

@michaoj, do you use Panther (Symfony\Component\Panther\PantherTestCase) or another tool using BrowserKit ?

No, my test suites does not rely yet on a browser driver

@fabpot fabpot closed this as completed Dec 7, 2019
fabpot added a commit that referenced this issue Dec 7, 2019
…s-grekas)

This PR was merged into the 3.4 branch.

Discussion
----------

[Cache] fix memory leak when using PhpArrayAdapter

| Q             | A
| ------------- | ---
| Branch?       | 3.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | Fix #34687
| License       | MIT
| Doc PR        | -

Thanks to @adrienfr, I've been able to understand what causes this massive memory leak when using `PhpArrayAdapter`:
![image](https://user-images.githubusercontent.com/243674/70262187-303b1b00-1794-11ea-9fcb-21ae29c31ff0.png)

When tests run, a new kernel is booted for each test case. This means a new instance of `PhpArrayAdapter` is created, which means it loads its state again and again using `include` for e.g. `annotations.php` in this example.

The first obvious thing is that we see this doing `compile::*`: this means PHP is parsing the same file again and again. But shouldn't opcache prevent this? Well, it's disabled by default because `opcache.enable_cli=0`. To prove the point, here is a comparison with the same tests run with `php -dopcache.enable_cli=1`. The comparison is swapped, but you'll get it:

![image](https://user-images.githubusercontent.com/243674/70262616-fb7b9380-1794-11ea-81c3-6fea0145a63b.png)

But that's not over: because of https://bugs.php.net/76982 (see #32236 also), we still have a memory leak when the included file contains closures. And this one does.

This PR fixes the issue by storing the return value of the include statement into a static property. This fits the caching model of `PhpArrayAdapter`: it's a read-only storage for system caches - i.e. its content is immutable.

Commits
-------

4194c4c [Cache] fix memory leak when using PhpArrayAdapter
nicolas-grekas added a commit that referenced this issue Dec 10, 2019
…s-grekas)

This PR was merged into the 4.3 branch.

Discussion
----------

[Cache] fix memory leak when using PhpFilesAdapter

| Q             | A
| ------------- | ---
| Branch?       | 4.3
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | Fix #34687
| License       | MIT
| Doc PR        | -

Similar to #34839 but for `PhpFilesAdapter`, as the "appendOnly" mode is a v4-only feature.

Commits
-------

0b46226 [Cache] fix memory leak when using PhpFilesAdapter
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants