Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Fix #63206: Fully support error/exception_handler stacking #5206

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

Closed
wants to merge 1 commit into from
Closed

Fix #63206: Fully support error/exception_handler stacking #5206

wants to merge 1 commit into from

Conversation

not-implemented
Copy link
Contributor

... even with null or inside the handler.

Always push the current user_error/exception_handler to the stack,
even when it is empty, so restore_error_handler() always works as
expected.

The user_error_handler is especially temporarily empty when we are inside
the error handler, which caused inconsistent behaviour before.

See attached test-cases for details.

PHP-Bug: https://bugs.php.net/bug.php?id=63206

… null or inside the handler

Always push the current user_error/exception_handler to the stack,
even when it is empty, so restore_error_handler() always works as
expected.

The user_error_handler is especially temporarily empty when we are inside
the error handler, which caused inconsistent behaviour before.
Copy link
Member

@nikic nikic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. I looked at some set_error_handler(null) uses in libraries, and it looks like they are either not affected by this change, or fixed by it (there were set_error_handler(null) + restore_error_handler() occurrences, which, if I understand right, will not do what is expected before this change.)

@not-implemented not-implemented marked this pull request as ready for review February 25, 2020 09:41
@nikic
Copy link
Member

nikic commented Feb 25, 2020

there were set_error_handler(null) + restore_error_handler() occurrences, which, if I understand right, will not do what is expected before this change.

Eh, thinking about this again, that particular case should work fine already, as the null handler doesn't get pushed. But still, I don't think this change will cause issues.

@not-implemented
Copy link
Contributor Author

Yes, I don't think, it will cause real issues - the backward-incompatibility is more of theoretical nature as it never worked as expected in this edge-case.

The only internal thing, I was not sure, is the cleanup of user_error_handlers ... but zval_ptr_dtor() seems to be safe for UNDEF values. And I didn't find any places where UNDEF causes problems in the C code.

@nikic
Copy link
Member

nikic commented Feb 25, 2020

The only internal thing, I was not sure, is the cleanup of user_error_handlers ... but zval_ptr_dtor() seems to be safe for UNDEF values. And I didn't find any places where UNDEF causes problems in the C code.

Yes, zval_ptr_dtor() is safe for IS_UNDEF. For master we may want to replace the use of UNDEF here with NULL. I don't think there's a reason to use UNDEF, and using it just means that we have to perform extra checks and mapping between undef <-> null.

@not-implemented
Copy link
Contributor Author

Cool, maybe for master it makes sense to additionally implement the "in-error-handler" flag instead of removing the error-handler temporarily to avoid recursion (as you suggested in https://bugs.php.net/bug.php?id=63206).

But maybe that is not so easy, because setting a custom error handler inside the error-handler should still work. I didn't think it through, anyway ;-)

@nikic
Copy link
Member

nikic commented Feb 25, 2020

Merged as 8c6a7c3 into 7.3.

But maybe that is not so easy, because setting a custom error handler inside the error-handler should still work. I didn't think it through, anyway ;-)

Yes, I think we would have to track the current "depth" of the error handler for that. May not be worthwhile after this change.

@not-implemented
Copy link
Contributor Author

Merged as 8c6a7c3 into 7.3.

@nikic: Cool, thanks!

Yes, I think we would have to track the current "depth" of the error handler for that. May not be worthwhile after this change.

Yes, probably not. It will only be relevant for very theoretical use cases in any case ;-)

nicolas-grekas added a commit to symfony/symfony that referenced this pull request Mar 23, 2020
This PR was merged into the 3.4 branch.

Discussion
----------

[Debug] fix for PHP 7.3.16+/7.4.4+

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

Should make tests green.
Follows php/php-src#5206, which is part of PHP 7.4.4 and 7.3.16.
The same patch is needed on the ErrorHandler component in 4.4 of course.

Commits
-------

b3d9a8a [Debug] fix for PHP 7.3.16+/7.4.4+
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.

2 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.