Bug #49664 [Com]: Clone causes Segmentation fault

Edit report at https://bugs.php.net/bug.php?id=49664&edit=1 ID: 49664 Comment by: andreas at schipplock dot de 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: 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. Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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