8000 Fix Inconsistent Exit Status in `proc_get_status` for PHP Versions Below 8.3 by Luc45 · Pull Request #53820 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

Fix Inconsistent Exit Status in proc_get_status for PHP Versions Below 8.3 #53820

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 8 commits into from
Closed

Fix Inconsistent Exit Status in proc_get_status for PHP Versions Below 8.3 #53820

wants to merge 8 commits into from

Conversation

Luc45
Copy link
Contributor
@Luc45 Luc45 commented Feb 7, 2024 •
edited
Loading
Q A
Branch? 5.4, 6.4, 7.0
Bug fix? yes
New feature? no
Deprecations? no
Issues N/A
License MIT

This PR addresses a bug in Symfony's Process component affecting PHP versions prior to 8.3. In these versions, calling proc_get_status multiple times on the same process resource only returns the correct exit status on the first call, with subsequent calls returning -1 due to the process being discarded. This behavior can lead to race conditions and incorrect process status reporting in Symfony applications.

To resolve this, the PR introduces a workaround that caches the first retrieved exit status. This cached status is then used for subsequent calls, ensuring consistent and accurate exit status reporting. This change aims to align the behavior with PHP 8.3, where this issue has been resolved natively.

Changes:

  • Added caching mechanism for the exit status in the Process component.
  • Ensured the cached status is used for subsequent proc_get_status calls if PHP version is below 8.3.

Proof of Concept:

To demonstrate the issue and the effectiveness of the fix, a proof of concept script is included below. This script uses Symfony's Process component to start a subprocess that outputs a message and exits with a specific status code. The script then attempts to retrieve the exit status of the process using getExitCode(). In PHP versions prior to 8.3, without the proposed fix, this script will often incorrectly report an exit code of -1 due to the race condition described earlier.

<?php

if ( getenv( 'OUTPUT' ) ) {
	#echo 'This should fail when "wait" gets large';
	sleep( 2 );
	echo 'This should fail even when "wait" is small';
	die( 123 );
}

use Symfony\Component\Process\Process;

require_once __DIR__ . '/vendor/autoload.php';

do {
	// Increasingly bigger waits.
	static $wait = 0;
	$wait += 100000;
	echo sprintf( 'Wait: %s', $wait ) . PHP_EOL;

	$p = new Process( [ 'php', __FILE__ ], __DIR__, [
		'OUTPUT' => 1,
	] );

	$p->start( function ( string $type, string $out ) use ( $p ) {
		echo $out . PHP_EOL;

		/**
		 * Calling most methods in Symfony Process that triggers
		 * updateStatus() can potentially trigger the -1 bug.
		 *
		 * @see Process::updateStatus()
		 */
		echo sprintf( 'Is Running: %s', $p->isRunning() ? 'Yes' : 'No' ) . PHP_EOL;
		echo sprintf( 'Exit Code: %s', $p->getExitCode() ) . PHP_EOL;
	} );

	while ( $p->isRunning() ) {
		usleep( $wait );
	}

	if ( ! $p->isSuccessful() ) {
		break;
	}
} while ( true );

$is_started = $p->isStarted();
$is_running = $p->isRunning();
$exit_code  = $p->getExitCode();

echo sprintf( 'Started: %s, Running: %s, Exit code: %s', $is_started, $is_running, $exit_code ) . PHP_EOL;

Impact:

  • This change only affects Symfony applications running on PHP versions below 8.3.
  • It improves the reliability of process status reporting in these environments.
  • No breaking changes or backward compatibility issues are introduced.

Testing:

I haven't added tests to this PR because:

  • This bug involves racing conditions, which is hard to replicate.
  • It's past 1 AM local time right now, and I've been debugging this for the past 6 hours.
  • The provided "Proof of Concept" can serve as an initial check to confirm the bug.

I'm really not the type of developer that does not write tests, but I beg my pardon for the reasons above.

Considerations

  • Based on the proc_open implementation, this fix might not be needed on Windows.
  • You can find additional context for this bug in this Stack Overflow answer.

@carsonbot carsonbot added this to the 7.1 milestone Feb 7, 2024
@carsonbot
Copy link

Hey!

I see that this is your first PR. That is great! Welcome!

Symfony has a contribution guide which I suggest you to read.

In short:

  • Always add tests
  • Keep backward compatibility (see https://symfony.com/bc).
  • Bug fixes must be submitted against the lowest maintained branch where they apply (see https://symfony.com/releases)
  • Features and deprecations must be submitted against the 7.1 branch.

Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change.

When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

@carsonbot
Copy link

Hey!

Thanks for your PR. You are targeting branch "7.1" but it seems your PR description refers to branch "5.4, 6.4, 7.0".
Could you update the PR description or change target branch? This helps core maintainers a lot.

Cheers!

Carsonbot

@Luc45 Luc45 changed the base branch from 7.1 to 5.4 February 7, 2024 03:41
@Luc45 Luc45 changed the base branch from 5.4 to 7.1 February 7, 2024 03:42
@Luc45
Copy link
Contributor Author
Luc45 commented Feb 7, 2024

Closed in favor of #53821 due to wrong base branch

@Luc45 Luc45 closed this Feb 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@lyrixx lyrixx Awaiting requested review from lyrixx

@yceruto yceruto Awaiting requested review from yceruto

@chalasr chalasr Awaiting requested review from chalasr

@dunglas dunglas Awaiting requested review from dunglas

@xabbuh xabbuh Awaiting requested review from xabbuh

Assignees
No one assigned
Labels
Bug Status: Needs Review
Projects
None yet
Milestone
7.1
Development

Successfully merging this pull request may close these issues.
2 participants
@Luc45 @carsonbot
0