Re: [Ekiga-devel-list] gmref_ptr

Julien Puydt wrote:
Eugen Dedu a écrit :
Julien Puydt wrote:
Eugen Dedu a écrit :
In services.cpp, ~ServiceCore executes pop_back(), and this function calls the destructor of the element ( 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 ();

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?

Ah, the comment is a leftover from the pre-gmref_ptr days : now we shouldn't care in which order they are stored... and probably we should

Snark, could you then remove the comment or, if you wish to maintain it, add before the comment the string "Obsolete comment" (or smth like this)?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]