Combination of phpdbg and Generator method causes memory leak

[ngyuki]

Description

Run phpdbg on object has generator method causes memory leaks.
It does not occur when run with php command.

---

The following code:

<?php
class A
{
    private $s;

    public function __construct()
    {
        $this->s = str_repeat('a', 1000000);
    }

    public function iterate()
    {
        yield 1;
    }
}

for ($i=0; $i<1000000; $i++) {
    $arr = iterator_to_array((new A())->iterate());
}

var_dump('ok', memory_get_peak_usage(true));

Resulted in this output:

$ phpdbg -qrr zz.php
[PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 1003520 bytes) in /w/zz.php on line 8]

But I expected this output instead:

$ php zz.php
string(2) "ok"
int(2097152)

PHP Version

PHP 8.3.0

Operating System

Debian 12

[iluuu1994]

/cc @bwoebi

[SakiTakamachi]

This is not a memory leak, an error that used up all of the memory available to php. Most likely, the original code was designed to use relatively memory, and phpdbg used more memory, causing the memory limit to be exceeded.

Try adding this at the beginning of your php code. I think the error will probably no longer occur.

<?php

ini_set('memory_limit', '512M');

[SakiTakamachi]

Oops, the case of using phpdbg, you may should set the memory limit on command args.

phpdbg -qrr -d memory_limit=512M zz.php

[ngyuki]

No, it may be that for some reason object is not freed by garbage collector.

<?php
class A
{
    public function __construct()
    {
        var_dump('__construct');
    }

    public function __destruct()
    {
        var_dump('__destruct');
    }

    public function iterate()
    {
        yield 1;
    }
}

$arr = iterator_to_array((new A())->iterate()); gc_collect_cycles();
$arr = iterator_to_array((new A())->iterate()); gc_collect_cycles();
$arr = iterator_to_array((new A())->iterate()); gc_collect_cycles();

var_dump('exit');

$ php zz.php
string(11) "__construct"
string(10) "__destruct"
string(11) "__construct"
string(10) "__destruct"
string(11) "__construct"
string(10) "__destruct"
string(4) "exit"

$ phpdbg -qrr zz.php
string(11) "__construct"
string(11) "__construct"
string(11) "__construct"
string(4) "exit"
string(10) "__destruct"
string(10) "__destruct"
string(10) "__destruct"

[iluuu1994]

There's some special handling of generators in phpdbg. It's possible that it keeps some reference around, preventing them from being freed. That does seem like a bug to me, but maybe there's a reason why the generators are kept around until the end of the script in this case. I don't know, hopefully @bwoebi can answer.

[ngyuki]

Also, this problem does not occur if generator is function rather than object method.

<?php
class A
{
    public function __construct()
    {
        var_dump('__construct');
    }

    public function __destruct()
    {
        var_dump('__destruct');
    }

    public function iterate()
    {
        yield 1;
    }
}

function iterate()
{
    yield 1;
}

$arr = iterator_to_array(iterate(new A())); gc_collect_cycles();
$arr = iterator_to_array(iterate(new A())); gc_collect_cycles();
$arr = iterator_to_array(iterate(new A())); gc_collect_cycles();

var_dump('exit');

$ phpdbg -qrr zz.php
string(11) "__construct"
string(10) "__destruct"
string(11) "__construct"
string(10) "__destruct"
string(11) "__construct"
string(10) "__destruct"
string(4) "exit"

[ranvis]

|| UNEXPECTED(zend_execute_ex != execute_ex) causing an extra addref to the class instance: d1dd474

[nielsdos]

Nice find! I think the original fix is simply wrong and we should just avoid the double destruction by checking for ZEND_CALL_TOP. I'll make a PR soon.