Edit report at https://bugs.php.net/bug.php?id=49664&edit=1
ID: 49664
Updated by: yohgaki@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:
@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.
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2013-04-06 17:45:36] dinesh dot joshi at yahoo dot com
This segmentation fault / coredump behavior is consistent with what lower level
languages like C. So IMHO this should not be considered a PHP bug. Just don't get
into infinite recursions. The language can't stop you from doing something stupid.
Here's a C program that demos the same behavior:
------------------------------
#include<stdio.h>
void fn() {
char buff[16*1024];
fn();
}
int main(void) {
fn();
}
------------------------------
------------------------------------------------------------------------
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