Re: [Ekiga-devel-list] gmref_ptr

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

Damien Sandras wrote:
> 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.

I would propose (as RM :o)) that someone :o) review very carefully the 
involved changes between 7603 and 7614 to see the problem, or revert 
those changes.

--
Eugen