Re: [Ekiga-devel-list] gmref_ptr

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

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.

--
Eugen