Re: [Ekiga-devel-list] gmref_ptr

[Julien Puydt <jpuydt free fr>]

Eugen Dedu a écrit :
> In services.cpp, ~ServiceCore executes pop_back(), and this function 
> calls the destructor of the element 
> (http://www.cplusplus.com/reference/stl/list/pop_back.html).  However, 
> the refcount of the objects so deleted is not necessarily 0 (you can 
> print their refcount just before deletion), so the destructor gets 
> called twice (and the second time this might generate a segmfault).

gmref_ptr<Foo> isn't the Foo itself. Destroying the gmref_ptr<Foo> 
decreases the refcount of the Foo object -- and this Foo object is 
destroyed only when that refcount reaches zero.

> Also, this might explain (yet to be analysed) your problem where a 
> refcount is 11, afterwards 1; the memory is wrongly delete-d when it has 
> refcount=11, and it is allocated again, which sets this field to 1.

Not sure... I have the impression you're confusing the lifetime of the 
object with the lifetime of the gmref_ptr to that object :-/

> Finally, I was wondering why is the whole gmref needed, since all the 
> pointers in service_core could be freed at the real end of ekiga, when 
> service_core itself is deleted (in engine_stop() from engine.cpp).

Not all objects are directly attached to the main Ekiga::ServiceCore 
object. gmref_ptr wasn't there from the start because I wanted a tighter 
control of how memory was handled. It finally prevented sharing some 
objects conveniently between some components, so gmref_ptr made memory 
management more automatic (with a cost).

Hope that explains some things :-)

Snark