Edit report at https://bugs.php.net/bug.php?id=49664&edit=1
ID: 49664
Comment by: dams@php.net
Reported by: patrik dot lermon at gmail dot com
Summary: Clone causes Segmentation fault
Status: Not a bug
Type: Bug
Package: Reproducible crash
Operating System: Linux
PHP Version: 5.*, 6 (2009-09-20)
Block user comment: N
Private report: N
New Comment:
This is now fixed in PHP 8.3.
Previous Comments:
------------------------------------------------------------------------
[2020-08-21 19:31:58] mtd at cardboardbox dot ri
> Infinite recursion crashes. There's no fix for that.
> if this happens in production code you will have no clue what caused it.
> This bug even brings down phpdbg.
And here it is. Infinite recursion crashes indeed, there's no fix for a badly designed script
running on your interpreter. However, what should crash is the running script, not the interpreter.
When the interpreter dies, nobody can know what and where caused the crash, it dies before it has a
chance to report that. A segfault can occur for many different reasons. Hell, bad hardware is a
potential cause. Therefore, the fact that the interpreter itself dies before it can report the
problem is the bug here, not the infinite recursion that causes it.
------------------------------------------------------------------------
[2015-12-03 14:53:21] andreas at schipplock dot de
Hello everyone,
this is a bug and it still happens in php7 (https://github.com/php/php-src/releases/tag/php-7.0.0).
I realize it's the endless recursion that causes it but someone is right in here: if this
happens in production code you will have no clue what caused it. If you see a fatal error then you
can, at least, see where it happened and you can try to fix it but this segmentation fault is
completely "dumb" in a way you can't even know where it happened.
This bug even brings down phpdbg.
------------------------------------------------------------------------
[2015-06-02 19:57:01] failureyousuck at gmail dot com
$ perl <<EOF
> use v5.14;
> use warnings;
>
> sub asub {
> asub();
> }
> asub();
> EOF
Deep recursion on subroutine "main::asub" at - line 5.
Out of memory!
This has been the case since at least Perl 5.8.x., that is, since 2002, I believe.
Basically every language except C (because C is DESIGNED for you to be able to do stupid stuff)
gives you something more useful than PHP. This is a bug.
http://en.wikipedia.org/wiki/Software_bug:
"A software bug is an error, flaw, failure, or fault in a computer program or system that
causes it to produce an incorrect or unexpected result, or to behave in unintended ways."
PHP is not designed (so far as I'm aware) to allow you to do stupid stuff. It's designed
to be easy (see also "no eq"). If it's not designed to allow you to do stupid stuff,
why does it let you do stupid stuff (WITH NO ERROR MESSAGE!) when it would be rudimentary to stop
it? That is VERY unexpected. Hell, at this point PHP has a traceback -- so you even already have a
stack counter!
Fixing enormous gaping holes in the language design is not a feature addition, it's a bug fix.
(And why does it matter whether or not Perl is broken too, anyway? Both are broken, only one is
broken, either way whichever is broken needs fixing...)
------------------------------------------------------------------------
[2015-03-19 20:59:04] yohgaki@php.net
@patrik Open new feature request for recursion limit if it's not exist.
IIRC, perl segfault (well at least old one). Ruby/Python has limit like 1000.
------------------------------------------------------------------------
[2015-03-19 20:44:30] patrik dot lermon at gmail dot com
The error is for instance handled in a civilised manner by hhvm (Fatal error: Stack overflow in
/in/aMjnT on line 6). So I guess infinite recursion crashes, and there is a way to realise this
without segfaulting.
I withstand if a high level programming language segfaults its design is broken, and thus this the
bug should remain open IMHO.
I'm not familiar with the underlaying design in php, but I guess that it just tries to
reference memory and hope for the best instead of actually perform some checks, which hhvm manages
to do. Again, I'm just guessing.
Segfault or stack overflow, does it matter?
Someone correct me if I'm wrong here, but as I understand it a stack overflow is realised and
reported by the interpreter itself, while a segfault is the actual OS realising that the process
tries to reference memory that it's not allowed to access and kills it. And if that is the case
the actual use case for fixing this would be to give the user a proper error message (what happened,
what file and line). Or if a proper exception handling was implemented in php (not mixing errors and
exceptions) I presume the programmer could even wrap his code in a try-catch and make his own
decision what to do in case of a stack overflow.
See http://3v4l.org/aMjnT
hhvm-3.3.1 - 3.5.1
a before cloning:
a: [- >]
Fatal error: Stack overflow in /in/aMjnT on line 6
Process exited with code 255.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=49664
--
Edit this bug report at https://bugs.php.net/bug.php?id=49664&edit=1