[php-src] Issue #7749: Segfault when recursive call is made

From: 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.

« previous php.bugs (#238361) next »