Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65702
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain tronic-media.com from 67.18.221.210 cause and error)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: =?utf-8?Q?=C3=81ngel_Gonz=C3=A1lez?= <keisial@gmail.com>, "Terry Ellison"
 <Terry@ellisons.org.uk>
Cc: internals@lists.php.net
References: <op.wrxrvqrn4ln631@rootp-server> <510E9031.9040209@gmail.com>
 <op.wryi8wsrlg86mn@rootp-server> <510F941F.4090309@gmail.com>
 <51110ED4.9040606@ellisons.org.uk>
Date: Thu, 07 Feb 2013 00:59:30 +0700
MIME-Version: 1.0
Content-Transfer-Encoding: Quoted-Printable
Message-ID: <op.wr3ixgqwlg86mn@rootp-server>
In-Reply-To: <51110ED4.9040606@ellisons.org.uk>
User-Agent: Opera Mail/12.12 (Win32)
Subject: Re: [PHP-DEV] (non)growing memory while creating anoymous functions
 via eval()
From: petrich@tronic-media.com (=?utf-8?Q?Hans-J=C3=BCrgen_Petrich?=)

Am 05.02.2013, 20:53 Uhr, schrieb Terry Ellison <Terry@ellisons.org.uk>:=


>
>   On 04/02/13 10:57, =C3=81ngel Gonz=C3=A1lez
>      wrote:
>    <snip>
>
>     The memory will stop growing (on my machine) at ~2491584 bytes and=
 the
> loop is able to run forever,
> creating each eval() furthermore uniqe ano-function's but not
> endless-filling Zend-internal tables.
>
>
>         but this still leaves the function record itself in the
> function_table hash so with a non-zero reference count and this
> doesn't get DTORed until request shutdown
>
>       Not familar with the Zend-internals but just about so i was imag=
ing
> and expecting it.
>
> That why i [still] also confused/wondering why in the 2nd example the
> memory will not grow *endless*.
> It seems that the function records in the function_table will be
> DTORed (or similar cleaned up) before request-shutdown at some point..=
.
>
> Could this be the case?
>
>
>>
>>     As you are reassigning $ano_fnc, the old closure is being destruc=
ted.
>> Had you used create_function(), it wouldn't happen.
>> Now the question is, if it is correctly freeing the functions (and it=
 is
>> good that it does so), why is it not doing it when they have differen=
t
>> lengths?
>>
>>
>
>    It's a bug. The Closure class DTOR does not delete the derefenced
>    function from the CG(function_table).
>    =

>    If you did the eval at line 20 in say /tmp/xx.php then the
>    INCLUDE_OR_EVAL instruction calls the Zend compiler with the args:
>
>      (1) the source to be compiled and
>
>      (2) the title "/tmp/x.php(20) : eval()'d code"
>
>    =

>    The compiler than gives the closure function a magic name:
>
>    =

>        "\0{closure}/tmp/x.php(20) : eval()'d code0xHHHHHHHH"
>
>    =

>    where 0xHHHHHHHH is the hex address of the "function" substring in
>    the evaluated string.  The compiler uses a zend_hash_update to
>    insert this into the CG(function_table).
>
>    =

>    What happens if you use a fixed length string replacing another
>    string of the same length dropping its refcount to 0 is that the
>    allocator is clever and will tend to reallocate the old one and
>    hence the address of the string is the same and the address of the
>    offset of the "function" substring is the same so it regenerates th=
e
>    same magic name -- pretty much as an accidental side-effect.  When
>    this happens, it's this hash update function that calls the DTOR on=

>    any pre-existing function with this name.
>
>    =

>    I simply put  a breakpoint on the relevant line in the
>    zend_do_begin_function_declaration() code and if you used a fixed
>    offset into the same string you only got one {closure} entry.  If
>    the allocation ended up "randomizing" the address, then the
>    {closure} entries grew  until memory exhaustion.
>
>    =

>    As I said -- interesting.  Need to think about the consequences
>    before I submit a bugrep.
>
>    Regards
>
>    Terry
>

Very interessting Terry. Would be great if the bug could be fixed.
If you post a bug report would you post the bug-report-url here also
that i (and/or other readers) can furthermore trace the discussion of th=
is issue?
Thank you again
Greetings