Re: [Ekiga-devel-list] Unfrozen code?
Julien Puydt wrote: Eugen Dedu a écrit : Julien Puydt wrote: Eugen Dedu a écrit : If you could fix http://bugzilla.gnome.org/show_bug.cgi?id=570008 I have unfortunately no idea what can start a thread on exit :-( Could you check if on your machine the following lines from engine.cpp are executed twice? if (service_core) delete service_core; I committed a simple patch today... does it change the situation? Nope :o( local-roster-bridge: Component to push contacts into the local roster *** glibc detected *** ekiga-snapshot: corrupted double-linked list: 0x0228eb90 *** === Backtrace: = /lib/libc.so.6[0x7f865dc591b8] [...] (sometimes Segmentation fault, sometimes the message above). (let's continue discussion in bugzilla.) -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Latest TRUNK
Hi, Am I the only one to experience audio problems when doing an outgoing call ? The device can't be opened, and I get a popup. Can somebody try with latest TRUNK of OPAL/PTLIB and Ekiga ? Thanks, -- _ Damien Sandras (o- //\Ekiga Softphone : http://www.ekiga.org/ v_/_ Be IP : http://www.beip.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsand...@ekiga.net ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Latest TRUNK
On Mon, Feb 23, 2009 at 8:35 PM, Damien Sandras dsand...@seconix.com wrote: Hi, Am I the only one to experience audio problems when doing an outgoing call ? The device can't be opened, and I get a popup. Can somebody try with latest TRUNK of OPAL/PTLIB and Ekiga ? I can probably tomorrow but I actually have a bug report with 3-4 people reporting similar issues on 3.0.2 on Fedora 10 (the update that was pushed to fix the status issue). Peter ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Latest TRUNK
Damien Sandras wrote: Hi, Am I the only one to experience audio problems when doing an outgoing call ? The device can't be opened, and I get a popup. Can somebody try with latest TRUNK of OPAL/PTLIB and Ekiga ? I have the same problem with audio in trunk, I thought I am the only one... -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] String freeze
Mike Massonnet a écrit : Le Sun, 22 Feb 2009 20:13:44 +0100, Julien Puydt jpu...@free.fr a écrit : Eugen Dedu a écrit : We hope to release ekiga 3.1.1 this Monday. Please note that this release corresponds to String Freeze! (http://live.gnome.org/TwoPointTwentyfive) String freeze... does that mean I can't hack on ekiga right now? Snark I sense a bug in the matr^W^W your mail client :) Well, I asked separately what the status was and got a go-on answer, then looked back a few mails and realized that string freeze wasn't announced as long ago as I remembered. So I ask again, because the changes I have in mind will probably break such a freeze. Snark ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] gmref_ptr
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_ptrFoo isn't the Foo itself. Destroying the gmref_ptrFoo decreases the refcount of the Foo object -- and this Foo object is destroyed only when that refcount reaches zero. Also, this might explain (yet to be analysed) your problem where a refcount is 11, afterwards 1; the memory is wrongly delete-d when it has refcount=11, and it is allocated again, which sets this field to 1. Not sure... I have the impression you're confusing the lifetime of the object with the lifetime of the gmref_ptr to that object :-/ Finally, I was wondering why is the whole gmref needed, since all the pointers in service_core could be freed at the real end of ekiga, when service_core itself is deleted (in engine_stop() from engine.cpp). Not all objects are directly attached to the main Ekiga::ServiceCore object. gmref_ptr wasn't there from the start because I wanted a tighter control of how memory was handled. It finally prevented sharing some objects conveniently between some components, so gmref_ptr made memory management more automatic (with a cost). Hope that explains some things :-) Snark ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
