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
Snark, could you then remove the comment or, if you wish to maintain it,
add before the comment the string "Obsolete comment" (or smth like this)?
--
Eugen
_______________________________________________
Ekiga-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
