Re: [Ekiga-devel-list] gmref_ptr

[Julien Puydt <jpuydt free fr>]

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.

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

Snark