php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #77216 recursive generator crash PHP
Submitted: 2018-11-28 21:58 UTC Modified: 2018-11-28 23:25 UTC
From: dams@php.net Assigned:
Status: Duplicate Package: Reproducible crash
PHP Version: 7.3.0RC6 OS: Irrelevant
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: dams@php.net
New email:
PHP Version: OS:

 

 [2018-11-28 21:58 UTC] dams@php.net
Description:
------------
When a generator calls itself (what an idea), PHP crashes. 

Test script:
---------------
<?php

function generator($n) {
    foreach(generator($n) as $l) {
        yield $l;
    }
}

foreach(generator(10) as $l) {
    print $l;
}

// Also https://3v4l.org/8FXB3

Expected result:
----------------
No crash, please.

Can I ask for recursive generators? No? Well, A warning or a nice fail will do. 

Actual result:
--------------
Segmentation fault: 11 On OSX

Process exited with code 139. On linux.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-11-28 22:17 UTC] requinix@php.net
-Status: Open +Status: Not a bug
 [2018-11-28 22:17 UTC] requinix@php.net
That's just plain infinite recursion.

Recursive generators work fine. https://3v4l.org/Hd0OE
 [2018-11-28 22:31 UTC] kalle@php.net
-Status: Not a bug +Status: Re-Opened
 [2018-11-28 22:31 UTC] kalle@php.net
@requinix, despite this being an infinite recursion, it should not crash but instead it should throw a memory_limit error, so keeping it open. Similar to other bugs I have reported in the past
 [2018-11-28 23:05 UTC] cmb@php.net
This is a stack overflow caused by infinite recursion of
execute_ex().  I doubt that we can catch such issues without
measurable performance impact.  Also, Xdebug has
xdebug.max_nesting_level[1] which should catch such issues during
development.  See also bug #69424.

In my opinion, this is not a bug.

[1] <https://xdebug.org/docs/basic>
 [2018-11-28 23:07 UTC] spam2 at rhsoft dot net
EVERY uncontrolled crash is a bug - it's that simple
 [2018-11-28 23:08 UTC] nikic@php.net
-Status: Re-Opened +Status: Duplicate
 [2018-11-28 23:08 UTC] nikic@php.net
Closing as duplicate of bug #64196, which is our canonical recursion stack overflow bug. All of these have the same root cause, but I'm not aware of any work to address this issue.
 [2018-11-28 23:15 UTC] requinix@php.net
A bit late but

> it should not crash but instead it should throw a memory_limit error,
Only if PHP runs out of memory. With head recursion the stack might run out before memory does.
 [2018-11-28 23:25 UTC] nikic@php.net
@requinix: In most cases, infinite recursion results in a memory limit error, because recursion is performed on the heap-allocated VM stack, rather than the C stack. However, if the recursion involves VM reentry, we do recurse on the C stack, which will ultimately lead to a stack overflow. This usually either happens because an extension that forces VM reentry is used (most profilers fall into this category), or because calls are indirected through internal functions (magic methods, or here, generators).

One "solution" to this problem is to catch the segfault that happens when we hit the stack guard page and display a nice error message in this case. But nobody has tried to implement this yet.
 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Sat Apr 10 12:01:23 2021 UTC