Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:59487 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 49459 invoked from network); 9 Apr 2012 07:10:02 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Apr 2012 07:10:02 -0000 Authentication-Results: pb1.pair.com header.from=dmitry@zend.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=dmitry@zend.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.199.177.89 as permitted sender) X-PHP-List-Original-Sender: dmitry@zend.com X-Host-Fingerprint: 212.199.177.89 il-mr1.zend.com Received: from [212.199.177.89] ([212.199.177.89:34850] helo=il-mr1.zend.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4E/EE-56433-84B828F4 for ; Mon, 09 Apr 2012 03:10:00 -0400 Received: from il-gw1.zend.com (unknown [10.1.1.22]) by il-mr1.zend.com (Postfix) with ESMTP id 4AD8A5FD06; Mon, 9 Apr 2012 10:08:12 +0300 (IDT) Received: from tpl2.home (10.1.10.25) by il-ex2.zend.net (10.1.1.22) with Microsoft SMTP Server id 14.1.255.0; Mon, 9 Apr 2012 10:09:45 +0300 Message-ID: <4F828B43.3090308@zend.com> Date: Mon, 9 Apr 2012 11:09:55 +0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: Laruence CC: Dmitry Stogov , PHP Internals References: In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.10.25] Subject: Re: [Bug #61649] zend gc should not mark persistent hashtable From: dmitry@zend.com (Dmitry Stogov) 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 this problem with other extensions? 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. Thanks. Dmitry. On 04/06/2012 04:32 PM, Laruence wrote: > Hi: > and, yes, extension can change their code to alloc a zend_gc_info > size(what I do now). > > however, I think, it's no need for zend_gc care about persistent > memorys, right? > > thanks > > > On Fri, Apr 6, 2012 at 8:21 PM, Laruence wrote: >> Hi Dmitry: >> >> 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) >> { >> >> .................. >> >> if (GC_ZVAL_GET_COLOR(zv) != GC_PURPLE) { >> GC_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, a warning will be show like: >> >> munmap_chunk(): invalid pointer 0x******* >> >> >> I have make a patch for this(https://bugs.php.net/bug.php?id=61649), >> if you think it's okey, I will commit it to all branches, >> >> thanks >> >> -- >> Laruence Xinchen Hui >> http://www.laruence.com/ > > >