Possible memory leak - 9 GB of RAM and 100 % processor use in 1 min, with only couple of Symfony packages

[TomasVotruba]

Still the same repository to create prefixed rector.phar.
https://github.com/rectorphp/compiler

When I run bin/console compile in that repository, I have to turn off my PHPStorm and my Chrome, or the box/scoper will crash it and disable all my Chrome extensions.

• box config: https://github.com/rectorphp/compiler/blob/master/box.json
• scoper config: https://github.com/rectorphp/compiler/blob/master/scoper.inc.php

It makes debugging very hard.

[TomasVotruba]

Info from Travis build

In one project I've used Travis to crawl over 500 pages in 55 minutes, but this thsi one breaks Travis.

The memory leak bubbles on mmap() function: https://travis-ci.com/rectorphp/compiler/builds/99545469#L679

It might give you a clue to solve this:

[TomasVotruba]

I just reproduced this with much less dependencies: deprecated-packages/dummy-phar#2

It will be probably something related to Symfony packages. This is composer.json:

{
    "bin": ["bin/run"],
    "require": {
        "php": "^7.1",
        "composer/xdebug-handler": "^1.3",
        "symfony/http-kernel": "^4.2",
        "symfony/console": "^4.2",
        "symfony/dependency-injection": "^4.2",
        "symfony/config": "^4.2",
        "symfony/yaml": "^4.2"
    },
    "autoload": {
        "psr-4": {
            "DummyPhar\\": "src"
        }
    }
}

[theofidry]

I see. I can see easily 3 ways were the leak can be (in order of likeliness):

• The parallel workers: Box is using amphp/parallel-functions to parallelise the scoping in order to make it more performant. I'm however not super familiar with the internals and it's not excluded that the package is subject to leaks.
• PHP-Scoper: I did not observe any leak so far even on a quite sizeable codebase (several dozens of thousands of LoCs) albeit quite slow. However PHP-Scoper does not really have an extensive benchmark/performance test suite so it can be easy to introduce a leak there by mistake. I'm sure you are familiar with it but PHP-Scoper extensively use PHP-Parser and do a lot of AST manipulation, so a leak there is very easy to produce.
• The Phar format: across the different projects to build PHARs there was always a couple of tricky points on how to build the PHAR in an efficient way and compress it without trouble. I hope I dealt with all those cases with Box but there is no guarantee.

The third case would be by far the worst one since it would likely require to tinker the Phar C extension...

Do you observe the same issue with --no-parallel and making sure that xdebug is disabled or that you are allowing box to restart the process without xdebug (box does it by default unless you have --no-restart or BOX_ALLOW_XDEBUG=1; this can be since in verbose mode)? If no then it means it's the first case, and if yes then it's a leak in PHP-Scoper

[theofidry]

@TomasVotruba is the issue still present? PHP-Scoper should be significantly ligher (on HumbugBox master)

[TomasVotruba]

I haven't tried since, so it's possibly gone. Let's close it for now