[php-src] Issue #7749: Segfault when recursive call is made
| From: | hktr92 | Date: | Sun, 12 Dec 2021 19:17:23 +0000 |
| Subject: | [php-src] Issue #7749: Segfault when recursive call is made | ||
| Groups: | php.bugs | ||
| Request: | Send a blank email to php-bugs+get-238361@lists.php.net to get a copy of this message | ||
Issue: https://github.com/php/php-src/issues/7749
Comment Author: hktr92
> Infinite recursion like this is considered a user bug. Since you have Xdebug installed, while
> developing and testing, you can set the
> [xdebug.max_stack_frames](https://xdebug.org/docs/all_settings#max_stack_frames) setting to a
> relatively large number and it will stop the script if you reach that limit.
>
> Regarding memory usage, it's quite possible - even common - to exhaust the stack before
> you exhaust memory.
I agree with the user bug part. but i disagree on other parts. psalm and/or phpstorm couldn't
catch this issue because it's a _runtime_ bug, not a _static analysis_ one, and it has nothing
to do with symfony / doctrine. the fact that i caught it there and narrowed it down to php reflects
this. i also thought at first it was induced by phpunit and/or zenstruck/foundry, but it's
plain simple.
i just compared this behavior with c++, rust (compiled languages) python and node (scripting
language). the outcome is the following:
- compiled languages halted the compilation with:
- c++: couldn't compile because
foo was calling bar, the latter
being undefined until later down the code (top-down read)
- rust: the compilation went brrr, but when trying to access the recursive function panicked with
"stack overflow" (explaining better what's happening)
- scripting languages halted the interpretation with:
- python: long recursive output, then raised RecursionError: maximum recursion depth
exceeded error
- node: same as python, but less output with Uncaught RangeError: Maximum call stack size
exceeded
The main reason I opened this issue is that even the code introduced an UB, it failed without
telling what's happening. a "vanilla" php setup does not contain xdebug, nor the
production build in our docker setup, both failing with silent segfault, thus:
1. making the code harder to debug
2. php not reporting the oom error before segfault
3. no static analysis safeguard was able to catch this
this ~~bug~~ feature is... well... _bugging_, especially those who's first at php **and**
introduces hours of debugging to them. even an experienced dev would have to waste some time to
debug why php fails to execute the code beforehand _before_ noticing the recursive call (which is,
of course, learned from past experience).
i don't think it has anything to do with raising the memory limits (which, btw, is a bad
practice, because it can cause unwanted oom kill in linux), nor with magic calls (these are also
kinda-sorta bad practice because of difficulty of static analysis). it's simply a weirdness on
how zend engine handles these userland issues without any apparent control.
imo it's okay if this wontfix, totally makes sense, but i don't think a hard
recursion limit won't impact that badly the performance of zend doing it's job.