I initially looked at the final fix when I discovered the issue.
Follow me out on this. This is the current code as-implemented in
r323563:
265 zval *obj;
266 MAKE_STD_ZVAL(obj);
267 if (Z_OBJ_HANDLER_P(*arg, cast_object)(*arg, obj, type
TSRMLS_CC) == SUCCESS) {
268 zval_ptr_dtor(arg);
269 *arg = obj;
270 *pl = Z_STRLEN_PP(arg);
271 *p = Z_STRVAL_PP(arg);
272 return SUCCESS;
273 }
274 efree(obj);
The issue that I originally identified (overwriting the argument
pointer) is still happening. Is there any reason for overwriting the
arg pointer? Wouldn't it be better to just do the Z_STRLEN_PP and
Z_STRVAL_PP operations on obj instead, and zval_ptr_dtor it as well
(instead of efree, as that way if a reference is stored somewhere it
won't result in a double free, or a segfault for accessing freed
memory)?
Thanks,
Anthony
On Mon, Feb 27, 2012 at 11:39 AM, Xinchen Hui <larue...@gmail.com> wrote:
> Sent from my iPad
>
> 在 2012-2-28，0:10，Anthony Ferrara <ircmax...@gmail.com> 写道：
>
>> Out of curiosity, why are you changing it to copy the object for the
>> result of the cast operation? cast_object should init the result
>> zval, so why go through the step of copying the starting object to
> plz look at the final fix： r323563
>
> thanks
>> r323563
>> Wouldn't it be easier just to do:
>>
>> if (Z_OBJ_HANDLER_PP(arg, cast_object)) {
>> zval *result;
>> ALLOC_ZVAL(result);
>> if (Z_OBJ_HANDLER_P(*arg, cast_object)(*arg, result, type TSRMLS_CC)
>> == SUCCESS) {
>> zval_ptr_dtor(arg);
>> *pl = Z_STRLEN_PP(result);
>> *p = Z_STRVAL_PP(result);
>> zval_ptr_dtor(result);
>> return SUCCESS;
>> }
>> zval_ptr_dtor(result);
>> }
>>
>> Keeping both completely separate, and not having the possibility of
>> corrupting the arg object pointer? As it is right now (with the patch
>> in the first mail), wouldn't the possibility still exist of nuking the
>> arg object pointer which could be used elsewhere (and hence cause the
>> memory leak and segfault when that variable is referenced again)?
>>
>> (Un tested as of yet, just throwing it out there as it seems kind of
>> weird to overwrite the arg pointer for what seems like no reason)...
>>
>> Anthony
>>
>>
>>
>> On Mon, Feb 27, 2012 at 10:22 AM, Richard Lynch <c...@l-i-e.com> wrote:
>>> On Mon, February 27, 2012 2:31 am, Laruence wrote:
>>>> On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogov <dmi...@zend.com>
>>>> wrote:
>>>>> Hi Laruence,
>>>>>
>>>>> The attached patch looks wired. The patch on top of it (r323563)
>>>>> makes it
>>>>> better. However, in my opinion it fixes a common problem just in a
>>>>> single
>>>>> place. Each call to __toString() that makes "side effects" may cause
>>>>> the
>>>>> similar problem. It would be great to make a "right" fix in
>>>>> zend_std_cast_object_tostring() itself, but probably it would
>>>>> require API
>>>> Hi:
>>>> before this fix, I thought about the same idea of that.
>>>>
>>>> but, you know, such change will need all exts who implmented
>>>> their own cast_object handler change there codes too.
>>>>
>>>> for now, I exam the usage of std_cast_object_tostring, most of
>>>> them do the similar things like this fix to avoid this issues(like
>>>> ZEND_CAST handler).
>>>>
>>>> so I think, maybe it's okey for a temporary fix :)
>>>
>>> Perhaps a better solution would be to make a NEW function that uses
>>> zval** and deprecate the old one with memory leaks.
>>>
>>> Old extensions remain functional, new extension consume less memory.
>>>
>>> (This presumes I actually understand the issue, which is questionable.)
>>>
>>> --
>>> brain cancer update:
>>> http://richardlynch.blogspot.com/search/label/brain%20tumor
>>> Donate:
>>> https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
>>>
>>>
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
