Am Freitag, den 08.05.2009, 17:40 +0200 schrieb Eugen Dedu: > Michael Rickmann wrote: > > Am Freitag, den 08.05.2009, 13:41 +0200 schrieb Eugen Dedu: > >> Hi, > >> > >> Windows build is currently delayed by a few bugs. Couldn't we just > >> create a windows build from the stable branch? Are there modifications > >> to be done or is it as simple as just build the branch instead of the > >> trunk? > >> > > I can try during weekend. What is the stable branch - the tar ball ekiga > > 3.2 ? My patches to build ekiga master with device detection you find in > > http://mail.gnome.org/archives/ekiga-devel-list/2009-May/msg00003.html > > http://sourceforge.net/tracker/?func=detail&aid=2785005&group_id=204472&atid=989748 > > Until upstream integrates this patch, couldn't this patch be applied > before building win version? This allows us to advance the win release... > Sorry for the late reply. Before answering I wanted to learn a bit about what naggs me. No, I do not think that releasing a Win32 Ekiga 3.2 is advisable before the so called "crash on exit" (COE) has been localized. First I would like to know whether COE is just a bug or two or something more general. Win32 is particularly affected. I cannot reproduce it under Linux though the valgrind output looks terrifying. I poked around a bit in contact-core replacing the current make_slot mechanism of chaining signals with the 3.02 one using sigc::mem_fun but with the new pointers to refcounted objects. I got rid of the emediate crash to find heap corruption:
Breakpoint 1 at 0x435dd0: file ../../../lib/engine/account/account-core.cpp, line 48. (gdb) b Ekiga::ChatCore::~ChatCore() Breakpoint 2 at 0x476325: file ../../../lib/engine/chat/chat-core.cpp, line 40. (gdb) b Ekiga::ContactCore::~ContactCore() Breakpoint 3 at 0x477e64: file ../../../lib/engine/addressbook/contact-core.cpp, line 49. (gdb) c Continuing. [Switching to thread 1080.0x4ec] Breakpoint 2, Ekiga::ChatCore::~ChatCore (this=0x8178398) at ../../../lib/engine/chat/chat-core.cpp:40 in ../../../lib/engine/chat/chat-core.cpp (gdb) 40 ../../../lib/engine/chat/chat-core.cpp: No such file or directory. c Continuing. Breakpoint 3, Ekiga::ContactCore::~ContactCore (this=0x814bf40) at ../../../lib/engine/addressbook/contact-core.cpp:49 in ../../../lib/engine/addressbook/contact-core.cpp (gdb) 49 ../../../lib/engine/addressbook/contact-core.cpp: No such file or directory. c Continuing. Breakpoint 1, Ekiga::AccountCore::~AccountCore (this=0x814bec0) at ../../../lib/engine/account/account-core.cpp:48 in ../../../lib/engine/account/account-core.cpp (gdb) warning: Heap corruption detected at 08195C90 warning: Heap corruption detected at 08195DA0 warning: Heap corruption detected at 081DDF30 Then Ekiga gets lost looping between WinXP system dlls. Without gdb that may last for several minutes before it crashes and Visual Studio jumps in. I think that Win32 Ekiga suffers from heap corruption which with the current code leads to an emmediate crash. After reading http://bugzilla.gnome.org/show_bug.cgi?id=570008 where you, Eugene reported COE back in January I went back to SVN version 7603 which was supposed to be still ok. For Win32 it is not. It does not emmediately crash but has the heap corruption. Ekiga has lost Win32 earlier. I read about Snark's heroic attempt to directly fix COE last November in http://mail.gnome.org/archives/ekiga-devel-list/2008-November/msg00044.html . I think I do not have to repeat that. Instead I am just working on a little single theaded app which models Ekiga with its service-core, secondary cores and services, the latter two using sigc++ signals to communicate. Except of exercising in C++ I would like to compare Ekiga's gmref_ptr, libboost's shared_ptr and a combination of shared_ptr and weak_ptr. I aggree, thinking about the consequences of storing pointers to refcounted objects in signals sounds rather theoretical. Regarding the valgrind logs which I have read so far, I think, I will come to the point where the Win32 heap mechanisms which we use with Mingw32 will give in. Back to the original question. You can make calls with Win32 Ekiga. But with a not obvious bug (like code page characters in UTF-8) you will have to live with the danger of heap corruption which may also appear during normal program usage when objects are freed. I vote for fixing the "crash on exit" feature first. There is no Windows stable branch at the moment. Regards Michael _______________________________________________ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list