Disable ini files when restarted by XdebugHandler

[ghost]

Disable use of (additional) ini files for workers when restarted by XdebugHandler

This relates to: phpstan/phpstan#5809

[staabm]

Does composer itself work for you with your setup (composer uses the same xdebug-handler internally)? I am wondering whether there is a issue with your setup, or with the xdebug handler, or the phpstan integration

[ghost]

Does composer itself work for you with your setup (composer uses the same xdebug-handler internally)? I am wondering whether there is a issue with your setup, or with the xdebug handler, or the phpstan integration

Composer works.

Have a look at this post: composer/xdebug-handler#137 (comment)

[johnstevenson]

This is a summary of my post on the linked issue:

This error is a result of #559 which adds code to allow the user to pass a custom ini file on the command-line so that it can be used in a worker process.

phpstan-src/src/Process/ProcessHelper.php

Lines 27 to 28 in 2c11075

	$phpIni = php_ini_loaded_file();
	$phpCmd = $phpIni === false ? escapeshellarg(PHP_BINARY) : sprintf('%s -c %s', escapeshellarg(PHP_BINARY), escapeshellarg($phpIni));

Unfortunately it overlooked xdebug-handler, which in this case had already performed a restart using a tmp ini file created from the loaded and additional ini files. Because the worker process is called without preventing additional ini files scanning, php loads the extensions from the main ini file (actually xdebug-handler's tmp ini) , then tries to reload them from the additional inis.

And because xdebug is loaded in the worker process, xdebug-handler performs another restart.

xdebug-handler has been designed to handle these situations with its persistent settings strategy: https://github.com/composer/xdebug-handler#persistent-settings

$xdebug = new XdebugHandler('phpstan');
$xdebug->setPersistent();
$xdebug->check();
unset($xdebug);

This creates a flexible xdebug-free environment for all child processes and in my view is the best solution.

[ondrejmirtes]

@johnstevenson So instead of this PR, the only thing we need to add is $xdebug->setPersistent();? Thank you.

[johnstevenson]

@ondrejmirtes Yes, correct

[ondrejmirtes]

Alright, just did that: 222e1c3

Can you please verify it works as expected? Thanks.

[johnstevenson]

Okay, you can probably get rid of the extra code that was added in ProcessHelper.php. I'll reproduce the various scenarios and check them just to confirm.

[ondrejmirtes]

What extra code?

[ondrejmirtes]

Also please wait a bit; the new commit hasn't yet built to phpstan/phpstan. The CI pipeline is full today.

[johnstevenson]

The extra code introduced in #559

Also please wait a bit; the new commit hasn't yet built to phpstan/phpstan.

I tend to specifically replicate these scenarious in my own testcase classes first. One day I'll put them on Github, when I've worked out a simple way to automate them!

[ondrejmirtes]

It's now in phpstan/phpstan dev-master, so you can test it :)

[johnstevenson]

@ondrejmirtes Great, this works nicely and keeps Xdebug out of all subprocesses.

you can probably get rid of the extra code that was added in ProcessHelper.php

I was wrong about this. Explicitly setting the loaded ini on the comand-line has no downsides when XdebugHandler has restarted the process, because everything is in a single ini file (which is made available to PHP through through PHPRC environment variable). However for the sake of clarity it should probably be amended to something like:

    $phpCmd = escapeshellarg(PHP_BINARY);

    if (XdebugHandler::getRestartSettings() === null && php_ini_loaded_file() !== false) {
        // Explicitly set ini file in case it was passed in on the command line
        $phpCmd .= ' -c ' .escapeshellarg(php_ini_loaded_file());             
    }
    
    $processCommandArray = [
      $phpCmd,
    ];