On Tue, 2008-05-27 at 12:05 +0530, Uthaiyashankar wrote:
> Supun Kamburugamuva wrote:
> > Hi,
> >
> > We use a ref count to keep track of the references to a openssl_pkey_t and
> > use it in the openssl_pkey_free method. In the openssl_pkey_create method we
> > are setting the ref count to 0. But since we are returning a pointer, ref
> > count should be set to 1. Also the free method assumes that in the create
> > method it will be set to one.
> >
> > This is the code in the free method.
> >
> > if(--(pkey->ref) > 0){
> > return AXIS2_SUCCESS ;
> > }
> >
> > Now lets assume we are having two pointers to the structure. One pointer is
> > created when the structure is create and other is when we copy the pointer.
> > But now our ref counter is 1 (In create method we set it to 0).
> >
> > Lets say we free those two pointers respectively. In both these free method
> > calls the above if statement will return false and the structure will be
> > free twice (double free). So we need to set the ref = 1 in the
> > openssl_pkey_create methods?
This will fail in Neethi. For example let's take the Algorithmsuite
struct. Say we set the ref = 1 at the creation. The Binding struct keeps
a pointer to Algotithmsuite struct so ref = 2. since Algorithmsuite is
an assertion the Assertion struct also keeps a pointer so ref = 3. But
Algorithmsuite free calls only twice. That is from Assertion_free and
binding_free. So in this case it will not be freed. IMHO we can't define
a hard rule to set ref=1 when creating the struct. If we are going to do
that then we should have done it at the beginning, otherwise we need to
do some major changes. The developer can decide whether to set it to 0
or 1 by looking at how it exists. If it is always inside another struct
and freed from some other struct better to keep the ref = 0. Otherwise
better to keep ref = 1.
> >
>
> +1. One other possibility is to increase reference just after creating.
> This is how all the other references are working. But I prefer to do
> that in Create method itself.
>
> Regards,
> Shankar.
> > Any comments?
> >
> > Supun..
> >
> >
>
