Re: [Ekiga-devel-list] gmref_ptr

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 just do nothing in that destructor ; but we shouldn't do it just now : I'm not confident about the state of the gui code yet.

Notice that you seem to think it's a memory issue, but the crash looks like a threading issue (on exit, no less!). :-/


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