-
-
Notifications
You must be signed in to change notification settings - Fork 564
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
Disable maximum_function_nesting
in Xdebug 3.0+ default settings to be more production-alike
#623
Conversation
The `xdebug.max_nesting_level` flag is a problematic flag that, while helping many people avoiding infinite recursion bugs in their code, does not prevent such problems in production environment, and leads to diverging runtime behavior between development and production environments. In practice, many un-experienced users usually install Xdebug, then run some off-the-shelf tool from somewhere, and they experience a crash that requires re-configuring Xdebug to either have a higher `max_nesting_level` or to be `-1` by default. This limit has initially been `100` (before Xdebug 2.3), then raised to `256`, and in general will keep raising as recursive execution usage increases. By disabling this behavior in the **default** configuration of Xdebug (feature still exists, if the end user willingly enables it), we align the behavior of complex recursive execution schemes in production environments to what developers run in their local environment.
maximum_function_nesting
in Xdebug 3.0+ default settings to make Xdebug more production-alike
maximum_function_nesting
in Xdebug 3.0+ default settings to make Xdebug more production-alikemaximum_function_nesting
in Xdebug 3.0+ default settings to be more production-alike
@@ -755,7 +758,7 @@ | |||
; -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/db ... ></response> | |||
; | |||
; | |||
;xdebug.remote_log = | |||
;xdebug.remote_log = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These were butchered by my editor: is that a problem for this patch?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The file is auto generated from the docs, as per the first few lines:
; This file is generated by the 'xdebug.org:html/docs/convert.php' robot
; for Xdebug 3.0.0-dev — do not modify by hand
The docs live in the xdebug.org repository, but don't worry about that, I can fix that myself.
Discussed this with @derickr @ https://chat.stackoverflow.com/transcript/message/50171493#50171493 In practice, Xdebug 3.0 will have multiple "modes", where the default mode has the recursion limit disabled. If that's the case (not sure if tests are needed), then this patch is potentially redundant with the new defaults, which already makes me super-happy 👍 |
@@ -0,0 +1,17 @@ | |||
--TEST-- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: this test is still valid, as it demonstrates that a nesting level of 10000 is ignored by the defaults
I am closing this PR because I don't want to the "maximum function nesting" feature to be an opt-in in "develop" mode. That mode of Xdebug is specifically there to assist in making sure your PHP does not crash — and it has saved my own goat plenty of times. If Xdebug 3's develop mode is not active, the nesting level should not kick in (but it currently does, I think, so I added a ticket). In Xdebug 3 I have also already changed the error message so that it is obvious that it is Xdebug that triggers this. |
Just a follow-up for reference: run your process with |
The
xdebug.max_nesting_level
setting is a problematic flag-alike that, whilesometimes helping in avoiding infinite recursion bugs,
does not prevent such problems in production environment, and leads
to diverging runtime behavior between development and production
environments.
In practice, many un-experienced users usually install Xdebug, then run
some off-the-shelf tool from somewhere, and they experience a crash that
requires re-configuring Xdebug to either have a higher
max_nesting_level
or to be
-1
by default.This limit has initially been
100
(before Xdebug 2.3), then raised to256
, and in general will keep raising as recursive execution usage increases.By disabling this behavior in the default configuration of Xdebug (feature
still exists, if the end user willingly enables it), we align the behavior
of complex recursive execution schemes in production environments to what
developers run in their local environment.
Note: users will still run into memory consumption issues due to stack frame
allocation, but at least that's the default behavior of PHP with or without Xdebug
installed.
Related: laminas/laminas-cli#40
/cc @boesing @geerteltink @weierophinney