-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[ErrorHandler] Avoid calling xdebug_get_function_stack() in xdebug >= 3.0 when not in develop mode #40787
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
[ErrorHandler] Avoid calling xdebug_get_function_stack() in xdebug >= 3.0 when not in develop mode #40787
Conversation
…tal Error situations
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:
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! I am going to sit back now and wait for the reviews. Cheers! Carsonbot |
I think the current code already handles the situation. It's just not released yet. |
It attempts to handle it yes. In an ideal world, we could avoid the call and avoid using the at-suppression/shut operator (a good php practice is if you can avoid @-suppression, you should). In the current unreleased codebase, the function is still called, and if a custom error handler is currently registered, it too will be triggered (I am seeing this behavior): https://www.php.net/manual/en/language.operators.errorcontrol.php
|
As explained in xdebug's doc, the php.ini setting can be overriden by an env var. This means this check won't work all the time. You're right about the silencing operator. Maybe we could set a temporary "null" error handler instead of using it. Would you mind giving it a try in this PR? |
You make a great point, ... I am inclined to just close this PR as I don't see any clean way of detecting the mode, and introducing another error handler to the stack doesn't feel like the right path. The @-supression is probably a good enough stopgap until proper mode detection is built-in to xdebug: xdebug/xdebug#733 Hopefully we can get this current fix with the @-suppression released soon? 😁 |
xdebug/xdebug#737 us the new PR |
This looks great! ❤️ Thank you very much, Derick! |
…h xdebug >= 3.0 when not in develop mode (fmata) This PR was merged into the 5.4 branch. Discussion ---------- [ErrorHandler] Do not call xdebug_get_function_stack() with xdebug >= 3.0 when not in develop mode | Q | A | ------------- | --- | Branch? | 5.4 | Bug fix? | yes | New feature? | no | Deprecations? | no | Issues | Fix #40677 | License | MIT The PR #40787 was rejected because of env var handling in xdebug_mode. xdebug/xdebug#737 allow us to get xdebug_mode in all cases so I think we can merge this PR safely. Tested on my setup successfully, I have no more warning. Thanks `@ralphschindler` :) Commits ------- a8114fe [ErrorHandler] Do not call xdebug_get_function_stack() with xdebug >= 3.0 when not in develop mode
When the application is already dealing with a FatalError, we should avoid calling
xdebug_get_function_stack()
in situations we know will produce another php_error from within xdebug itself.https://github.com/xdebug/xdebug/blob/90fa09d230603f3d972dd00cf02440cf3d35d2ee/src/develop/stack.c#L1003-L1007
xdebug_get_function_stack()
can be called in xdebug < 3.0 (ie:ini_get('xdebug.mode')
will return false since it doesn't not existOR
xdebug_get_function_stack()
can be called in xdebug >= 3.0 whenini_get('xdebug.mode')
returnsdevelop
.