Edit report at https://bugs.php.net/bug.php?id=49664&edit=1
ID: 49664
Comment by: failureyousuck at gmail dot com
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:
$ 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...)
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2015-03-19 19:52:27] omars@php.net
I'd say the best way to handle this, could be using an ini directive.
------------------------------------------------------------------------
[2014-04-03 12:15:14] mike@php.net
@cataphract, why was this re-opened?
AFAICT there won't be a recursion counter.
------------------------------------------------------------------------
[2013-08-07 20:19:34] initrd dot gz at gmail dot com
C lets you do a lot of stuff you aren't supposed to do. Just because C allows it
doesn't mean higher level languages like PHP should. An out of memory error is
much more helpful than a segfault, which could come from anything. Also, segfaults
have historically lead to exploits.
------------------------------------------------------------------------
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