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?
