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

Fix enum type reflection (https://github.com/php/php-src/issues/8444) #1

Closed
wants to merge 1 commit into from

Conversation

iamluc
Copy link
Owner

@iamluc iamluc commented Apr 28, 2022

No description provided.

@iamluc
Copy link
Owner Author

iamluc commented Apr 29, 2022

Not fast enough.... php#8455

@iamluc iamluc closed this Apr 29, 2022
iamluc pushed a commit that referenced this pull request Apr 20, 2023
…hp#10393)

The CSPRNG failing should be rare nowadays, but it *might* happen and without
this patch it's hard for the user to find out why the salt generation failed:
The error message is not actionable.

This patch will automatically set the CSPRNG exception to the `$previous`
exception of the ValueError that is thrown, allowing the developer to determine
the cause of the salt generation failure.

Before:

    Fatal error: Uncaught ValueError: Unable to generate salt in php-src/test3.php:3
    Stack trace:
    #0 php-src/test3.php(3): password_hash(Object(SensitiveParameterValue), '2y')
    #1 {main}
      thrown in php-src/test3.php on line 3

After:

    Fatal error: Uncaught Random\RandomException: Cannot open /dev/urandom: No such file or directory in php-src/test3.php:3
    Stack trace:
    #0 php-src/test3.php(3): password_hash(Object(SensitiveParameterValue), '2y')
    #1 {main}

    Next ValueError: Unable to generate salt in php-src/test3.php:3
    Stack trace:
    #0 php-src/test3.php(3): password_hash(Object(SensitiveParameterValue), '2y')
    #1 {main}
      thrown in php-src/test3.php on line 3
iamluc pushed a commit that referenced this pull request Apr 20, 2023
…#10533)

Commit a211956 added a TSRM destructor, but that destructor
will get called by tsrm_shutdown(), which is after opcache.so has
already been unloaded, resulting in a shutdown crash, e.g.:

  #0  0x00007fad01737500 in ?? ()
  #1  0x000055ac54e723c4 in tsrm_shutdown () at TSRM/TSRM.c:194
  #2  0x000055ac54c42180 in main (argc=80, argv=0x55ac57bc14d0) at sapi/cli/php_cli.c:1388

By calling ts_free_id() before opcache.so gets unloaded, we can easily
fix this crash bug.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant