Re: [Ekiga-devel-list] gmref_ptr

[Damien Sandras <dsandras seconix com>]

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.