Hi All,
I am not getting exactly what is the issue in refcount with reference
variable. One liner will be great for me to understand.
Anyway php-5 is not free of such refcount issues. One example is given
below. This code is a reduced form of xoops content Management
application's one activity which causes double free error.
<excerpts_of_my_mail_to_list_48_days_back>
<?php
class MyTextSanitizer
{
var $smileys=array()
function MyTextSanitizer() {}
function getSmileys()
{
return $this->smileys;
}
}
$myts = new MyTextSanitizer();
$smiles =& $myts->getSmileys(); //calling by ref alone causes improper
?>
The opcodes for the above script
ZEND_FETCH_CLASS
ZEND_NEW (Increases the refcount of smileys array from 1 to 2.
zend_declare class made it 1 from 0)
ZEND_JMP_NO_CTOR (Not executed)
ZEND_INIT_CTOR_CALL (No change in smileys refcount)
ZEND_DO_FCALL_BY_NAME(No change in smileys refcount)
ZEND_FETCH_W(No change in smileys refcount)
ZEND_ASSIGN(No change in smileys refcount)
ZEND_FETCH_R(No change in smileys refcount)
ZEND_INIT_METHOD_CALL(No change in smileys refcount)
ZEND_DO_FCALL_BY_NAME(Increases the refcount of smileys array from 2 to
3)
ZEND_FETCH_W(No change in smileys refcount)
ZEND_ASSIGN_REF(Increases the refcount of smileys array from 3 to 1.
_get_zval_ptr_ptr on &opline->op2 makes it 3 to 2.
zend_assign_to_variable_reference(&opline->result,
get_zval_ptr_ptr(&opline->op1, EX(Ts), BP_VAR_W), value_ptr_ptr, EX(Ts)
TSRMLS_CC); decreases it from 2 to 1)
ZEND_RETURN
ZEND_HANDLE_EXCEPTION
object destructor reduces the refcount from 1 to 0 and destroys the
$smileys. zend_destroy_class now attempts to destroy it again. This
causes a segfault.
With regards
Kamesh Jayachandran
</excerpts_of_my_mail_to_list_48_days_back>
On Mon, 30 May 2005 18:25:31 +0300 (EEST), "Jani Taskinen"
<[EMAIL PROTECTED]> said:
>
> Switching to PHP 5 (.1) here is not an option yet either.
> (and nobody can guarantee this same bug doesn't exist in it).
>
> Regarding the magnitude: It's pretty damn high, if you look at how
> many bug reports we've got about reference issues and large (huge)
> codebases. (where finding the short reproducing script is
> impossible)
>
> --Jani
>
>
> On Mon, 30 May 2005, Zeev Suraski wrote:
>
> > At 17:10 30/05/2005, Derick Rethans wrote:
> >> Not fixing it is *not* an option. You fix something that's broken - you
> >> don't leave it broken. That's called responsibility. And no, switching
> >> to PHP 5 is not an option either.
> >
> > Sorry Derick, but you saying that not fixing it and/or that switching to
> > PHP 5
> > are not valid options doesn't mean that they're not valid options. I think
> > that with the rarity of this issue and even higher rarity of it actually
> > causing problems, taking this approach is extremely valid. Breaking binary
> > compatibility inside a 'PHP version family' on the other hand is not an
> > option, we've decided not to do this 3 or 4 years ago, and I don't see any
> > reason to break this decision at all.
> >
> > I for one think that (a) providing info and workarounds, and (b) pointing
> > people to use PHP 5 is a completely acceptable solution to a problem of
> > this
> > magnitude, when compared to the cost of fixing it. Let's see what others
> > think.
> >
> > Zeev
> >
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
http://www.fastmail.fm - IMAP accessible web-mail
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
