Re: [Ekiga-devel-list] gmref_ptr

[Eugen Dedu <Eugen Dedu pu-pm univ-fcomte fr>]

Julien Puydt wrote:
> 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.

Hm... seems you're right.

I receive the segm fault when deleting gtk-frontend because gtk-core was 
already destroyed.  Now please look at the order of add/delete in this 
code from services.cpp:

Ekiga::ServiceCore::~ServiceCore ()
{
  /* this frees the memory, if we're the only to hold references,
   * and frees the last first -- so there's no problem
   */
  while (services.begin () != services.end ()){
    services.pop_back ();
  }
}

bool
Ekiga::ServiceCore::add (gmref_ptr<Service> service)
{
  bool result = false;

  if ( !get (service->get_name ())) {

    services.push_front (service);
    service_added (service);
[...]

Shouldn't be push_front with pop_front, or back with back?

--
Eugen