Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59497
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.42 as permitted sender)
MIME-Version: 1.0
Sender: laruence@gmail.com
In-Reply-To: <4F828B43.3090308@zend.com>
References: <CABBJUpeOe4m_+_db8HsUnOjXqjnjaRwGzq_CpqAfy0i9wh4sbA@mail.gmail.com>
 <CABBJUpc3uwE3oQg6f=BgGa9M=TKgRpw-1J9XRq+7Xf1v70bt5A@mail.gmail.com> <4F828B43.3090308@zend.com>
Date: Mon, 9 Apr 2012 18:56:02 +0800
Message-ID: <CABBJUpcEnXj6dNGuPOWSxGMWP7=x7AvR82O8EDL_+h3kM_9nxQ@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: Dmitry Stogov <dmitry@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Bug #61649] zend gc should not mark persistent hashtable
From: laruence@php.net (Laruence)

On Mon, Apr 9, 2012 at 3:09 PM, Dmitry Stogov <dmitry@zend.com> wrote:
> Hi Laruence,
>
> I think your patch is right, but I've never seen this problem before.
> Is it related to your own extension? What does it do? Why we didn't see t=
his
> problem with other extensions?
a persistent configure extension,  it loads all ini configure file at MINIT=
.

>
> Finally, I think that such persistent HashTables must be very rare, so
> introducing additional check would slowdown the engine. So allocating
> zend_gc_info may be a better solution.
okey, it's really rare usages :)

thanks
>
> Thanks. Dmitry.
>
>
> On 04/06/2012 04:32 PM, Laruence wrote:
>>
>> Hi:
>> =C2=A0 =C2=A0and, yes, =C2=A0extension can change their code to alloc a =
zend_gc_info
>> size(what I do now).
>>
>> =C2=A0 =C2=A0however, I think, it's no need for zend_gc care about persi=
stent
>> memorys, right?
>>
>> thanks
>>
>>
>> On Fri, Apr 6, 2012 at 8:21 PM, Laruence<laruence@php.net> =C2=A0wrote:
>>>
>>> Hi Dmitry:
>>>
>>> =C2=A0 zend gc was introducted in 5.3
>>>
>>> thinking of a zval which is a Hashtable allocated by a extension in
>>> persistent,
>>> and it also has hashtable children in it,
>>>
>>> then , if the extension return this to php script:
>>>
>>> array_init(return_value);
>>> zend_hash_copy(Z_ARRVAL_P(return_value),
>>> Z_ARRVAL_P(persitent_zval_hashtable),
>>> ***)..
>>>
>>> since zval_copy_ctor does shallow copy, so the persistent array return =
to
>>> the
>>> php
>>> script.
>>>
>>>
>>> then if it happen to be parsed by zval_ptr_dtor, then the persistent
>>> array will
>>> be
>>> parsed by gc_zval_possible_root,
>>>
>>> ZEND_API void gc_zval_possible_root(zval *zv TSRMLS_DC)
>>> {
>>>
>>> ..................
>>>
>>> =C2=A0 =C2=A0if (GC_ZVAL_GET_COLOR(zv) !=3D GC_PURPLE) {
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0GC_ZVAL_SET_PURPLE(zv);
>>> ..................
>>>
>>> then the malloc info of the block(not sure before or after) will be
>>> polluted.
>>>
>>> then when the extension try to free the block, =C2=A0a warning will be =
show
>>> like:
>>>
>>> munmap_chunk(): invalid pointer 0x*******
>>>
>>>
>>> I have make a patch for this(https://bugs.php.net/bug.php?id=3D61649),
>>> if you think it's okey, =C2=A0I will commit it to all branches,
>>>
>>> thanks
>>>
>>> --
>>> Laruence =C2=A0Xinchen Hui
>>> http://www.laruence.com/
>>
>>
>>
>>
>



--=20
Laruence =C2=A0Xinchen Hui
http://www.laruence.com/