lucy-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marvin Humphrey (JIRA)" <j...@apache.org>
Subject [lucy-issues] [jira] [Commented] (CLOWNFISH-37) Order of refcount manipulation when overwriting
Date Thu, 23 Apr 2015 23:11:38 GMT

    [ https://issues.apache.org/jira/browse/CLOWNFISH-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14510038#comment-14510038
] 

Marvin Humphrey commented on CLOWNFISH-37:
------------------------------------------

I consider this bug minor at the present time because it's impossible to trigger it from Perl-space
(the Perl-space caller will own a refcount so the refcount of the member var will always be
at least 2) and we haven't seen it in the wild.  However, it's important to fix going forward.

> Order of refcount manipulation when overwriting
> -----------------------------------------------
>
>                 Key: CLOWNFISH-37
>                 URL: https://issues.apache.org/jira/browse/CLOWNFISH-37
>             Project: Apache Lucy-Clownfish
>          Issue Type: Bug
>          Components: Core
>            Reporter: Marvin Humphrey
>            Priority: Minor
>             Fix For: 0.5.0
>
>
> There are a number of places in Clownfish where we decref a member variable then overwrite
it with an incref'd argument.  This can cause problem if for example a value overwrites itself,
because the decref can cause the refcount to fall to 0.
> We should instead first capture the incref to a temp variable, then decref, then overwrite.
> {code}
> void
> Foo_Set_Thing_IMP(Foo *self, Obj *thing) {
> -    DECREF(self->thing);
> -    self->thing = INCREF(thing);
> +    Obj *temp = INCREF(thing);
> +    DECREF(self->thing);
> +    self->thing = temp;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message