Le mardi 24 février 2009 à 18:26 +0100, Eugen Dedu a écrit : > 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 > >>>> (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? > >> > > > > 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. > > If I put services.pop_front(), I do not have a crash anymore. > > Also, with .pop_back(), the crash appears at gtk-frontend.cpp, > ~GtkFrontend, line > gtk_widget_destroy (addressbook_window); > I supposed it's because gtk-core is already destroyed, isn't true? > > > Notice that you seem to think it's a memory issue, but the crash looks > > like a threading issue (on exit, no less!). :-/ > > If it is a threading issue, then it should not be 100% reproducible on > my machine. I suspect a memory issue because valgrind also tell about > accessing memory in a freed zone.
I can not reproduce, but it becomes urgent to fix this, as well as the audio problem. Otherwise, no ekiga 3.2. _______________________________________________ Ekiga-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
