Re: [Ekiga-devel-list] windows stable branch

[Michael Rickmann <mrickma gwdg de>]

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