On 12/31/2012 10:59 AM, Mike Mitchell wrote:
> As near as I can tell only Comm::ConnOpener::InProgresConnectRetry()
> and Comm::ConnOpener::DelayedConnectRetry() duplicate the CommOpener
> object (by calling ptr->valid()).
That call to CbcPointer::valid() just returns an existing [valid]
pointer. It does not create anything new.
> It looks like the original is
> destructed, but I'm not sure if that is correct.
The "delete p" call looks correct to me -- we do not need that pointer
any more after the event callback has been called. It has been allocated
with "new Pointer" in the same file.
However, there may be other cbdata leaks, of course. I often find
scripts/find-alive.pl useful for finding those kinds of leaks. However,
that script may get out of sync so use with care! You may need the most
recent version from trunk (r12557) as a starting point.
> cbdataInternalFree() will decrement the lock count, but before it
> does it first checks and clears the "valid" flag. If the "valid" flag
> is not set, cbdataInternalFree asserts. If it is set, it clears the
> "valid" flag and then decrements the lock count.
Yes, this is intentional. Cbdata locking is separate from cbdata
validity. A cbdata user may posses a locked pointer to invalid data.
Such user will not be able to use the data (but will be able to unlock
it, which may result in the data being freed).
> I'm very confused about the way cbdata is working. I'm guessing that
> the "valid" flag is getting cleared before all the locks are removed,
> which will prevent any more locks from being removed.
No, cbdata is not reference counting where all data users are the same
and the data is simply deallocated with the last use.
With cbdata, the owner of the data allocates and frees it. All others
lock and unlock it. Freeing means either deallocating or, if
deallocation is not possible, just marking as invalid (this tells all
others that they cannot use the data). Locked data cannot be
deallocated. Invalid data cannot be used (even if locked). Invalid data
will be deallocated when the last lock is gone.
In theory, there is one cbdata owner and many "other users". In
practice, it gets messy.
HTH,
Alex.
Received on Mon Dec 31 2012 - 19:47:35 MST
This archive was generated by hypermail 2.2.0 : Tue Jan 01 2013 - 12:00:33 MST