Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:28213
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.132.241 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=UXdO7UMBeV/4jWg8l0MZeKW8nHRI3UwCwvwB7qsFqksW7fbelTp8dSgHMGPN1E0v/5sH8sPw8LjzfHPvLl8xQtI3ra8A3A0DbpvQ0Gsh1h5FXy35frLQI8JeZzkelCoxdawQGzXalSZ2G0Z+hhAjSSB8jAXwiGYVueODRYlBj6c=
Message-ID: <45E98EA6.4040108@googlemail.com>
Date: Sat, 03 Mar 2007 15:05:10 +0000
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: "Frank M. Kromann" <frank@kromann.info>, 
 PHP internals list <internals@lists.php.net>
References: <11728540521160000@9866357972520000.9866341568840000>
In-Reply-To: <11728540521160000@9866357972520000.9866341568840000>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: COM extension defects: Patch for defect 35872
From: andy.wharmby@googlemail.com (Andy Wharmby)

Hi Frank
    Thanks for checking my patch out. I will drop code into HEAD on 
Monday and then email Ilia for OK to drop into 5.2
Regards
    Andy


Frank M. Kromann wrote:
> Hi ANdy,
>
> Looks good to me. Nice and clean.
>
> - Frank
>
>   
>> Hi Internals,
>>       Below are details of a suggested patch for COM extension defect 
>> 35872 (http://bugs.php.net/bug.php?id=35872) for review/approval.
>> All comments welcome; good or bad.
>>
>> Regards
>>    Andy
>>
>> Andy Wharmby
>> IBM United Kingdom Limited
>> Winchester, England SO21 2JN
>> E-mail: andy_wharmby@uk.ibm.com
>>
>> Using supplied testcase the backtrace is as follows:
>>
>>     php6ts_debug.dll!zend_object_store_get_object(_zval_struct * 
>> zobject=0x009c19e8, void * * * tsrm_ls=0x009659a8)  Line 263 + 0x1b   
>>     
> C
>   
>>      php6ts_debug.dll!zend_objects_get_address(_zval_struct * 
>> zobject=0x009c19e8, void * * * tsrm_ls=0x009659a8)  Line 144 + 0xd    C
>>      php6ts_debug.dll!zend_std_object_get_class(_zval_struct * 
>> object=0x009c19e8, void * * * tsrm_ls=0x009659a8)  Line 1074 + 0xd    C
>>      php6ts_debug.dll!zend_get_class_entry(_zval_struct * 
>> zobject=0x009c19e8, void * * * tsrm_ls=0x009659a8)  Line 239 + 0x13   
>>     
> C
>   
>>      php6ts_debug.dll!disp_destructor(php_dispatchex * disp=0x00194460) 
>>     
>
>   
>> Line 562 + 0x10    C
>>      php6ts_debug.dll!dispatch_dtor(_zend_rsrc_list_entry * 
>> rsrc=0x009c3230, void * * * tsrm_ls=0x009659a8)  Line 60 + 0x9    C
>>      php6ts_debug.dll!list_entry_destructor(void * ptr=0x009c3230)  Line
>>     
>
>   
>> 184 + 0x10    C
>>      php6ts_debug.dll!zend_hash_apply_deleter(_hashtable * 
>> ht=0x00968290, bucket * p=0x009c31d8)  Line 836 + 0xf    C
>>      php6ts_debug.dll!zend_hash_graceful_reverse_destroy(_hashtable * 
>> ht=0x00968290)  Line 871 + 0xd    C
>>      php6ts_debug.dll!zend_destroy_rsrc_list(_hashtable * ht=0x00968290,
>>     
>
>   
>> void * * * tsrm_ls=0x009659a8)  Line 240 + 0x9    C
>>      php6ts_debug.dll!zend_deactivate(void * * * tsrm_ls=0x009659a8)  
>> Line 1358 + 0x1e    C
>>      php6ts_debug.dll!php_request_shutdown(void * dummy=0x00000000)  
>> Line 1429 + 0x9    C
>>      php.exe!main(int argc=0x00000003, char * * argv=0x009658f8)  Line 
>> 1306 + 0xa    C
>>      php.exe!mainCRTStartup()  Line 398 + 0x11    C
>>
>> We fail in zend_object_store_get_object() after the objects store has 
>> been destroyed earlier in request shutdown by
>>     
> zend_objects_store_destroy().
>   
>> Which is very similar to defect 34617 
>> (http://bugs.php.net/bug.php?id=34617).
>>
>> The reference to the object store is caused by the trace()  call in 
>> disp_destructor(). This call to trace() should probably be a NOOP in a 
>> non-debug build
>>  but we still need to fix reported problem so DEBUG builds don't hit the
>>     
>
>   
>> problem. I will raise a separate defect to disable the trace calls in 
>> non-DEBUG builds.
>>
>> I have resolved the problem reported under defect 35872 by defining a 
>> new boolean flag "rshutdown_started" in COMG which is set to false by 
>> COM RINIT
>> routine and true by  the COM RSHUTDOWN routine. This allows the COM code
>>     
>
>   
>> to avoid reference to the object store if invoked during request
>>     
> shutdown.
>   
>> The trace calls themselves have been modified to add the object address
>>     
>
>   
>> to allow entries referring to the same object to be correlated  even if
>>     
>
>   
>> the object name is not
>> available.
>>
>> Fixing code in disp_destructor revealed a similar issue in FETCH_DISP 
>> macro which is fixed in a same  way.
>>
>> The full patch; built against CVS HEAD is attached. 
>>
>>
>>     
>
>
>
>
>