Re: [Ekiga-devel-list] Win32 Vista terminate problem

[Michael Rickmann <mrickma gwdg de>]

Damien Sandras schrieb:
> Le mercredi 22 juillet 2009 à 23:22 +0200, Michael Rickmann a écrit :
> > Damien Sandras schrieb:
> > > Le mercredi 22 juillet 2009 à 19:49 +0200, Michael Rickmann a écrit :
> > > > I have a Vista notebook available for three days only. As already 
> > > > reported Ekiga has to be killed at shutdown. It seems a pecularity of 
> > > > Vista  which can be overcome by several means.
> > > > if (Vista)
> > > > 1) Wait at the end of the main thread ca. 5 secs, or
> > > > 2) do Wait 100 msec, enumerate Ekiga's threads
> > > >     while (num_threads > 1)
> > > > The second possibility seems cleaner but is more work and will not look 
> > > > nice. What shall I do?
> > > Do we have a bt to know why it deadlocks?
> > > Most probably Robert can give us a hint in that case...
> > Yes, any deeper knowlege would be helpful here. At the moment I am 
> > poking around. So far I found out that it is just a matter of time. If I 
> > put a  MessageBox which you have to click at the end of the Windows code 
> > Ekiga terminates under Vista properly. XP and 7Ultimate do not need that.
> > The overall picture is that Ekiga's main thread exits and ptlib and opal 
> > are supposed to clean up their threads. The last one is the ptlib 
> > housekeeper thread.
>
> I suppose it is extremely difficult to run Ekiga in gdb, hit ctrl-C when
> it deadlocks and type 'threads apply all bt' ? The difficult part being
> the Ctrl-C. Every time I tried, it was exiting gdb instead of
> interrupting the program execution or do you have a tip for that ?
> Robert will certainly ask for a backtrace.
> Does the -d4 tell something interesting? (compared to a working version,
> ie XP).
As to the ctrl-C, I got the work around from
http://cygwin.com/ml/cygwin/2006-06/msg00361.html working today,
unfortunately to late to test on the Vista computer of my daughter,
she has left again. What I do: 1) start Ekiga, 2) look up its PID in
taskmanager, 3) start gdb from an Msys shell and attach to the PID,
4) in a second Msys run debugbreak.exe PID . The debugbreak which I used
you find in
http://wwwuser.gwdg.de/~mrickma/ekiga/others/debugbreak.zip .

Let me tell what I found out about Ekiga's termination under Vista,
first in general, then with a bit more detail.

1) Vista without service pack and without updates: crash on exit
2) Vista without service pack regularly updated: stuck on exit
    this is the state of my daughters notebook
3) Vista with SP1 but without updates: stuck on exit
4) Vista with SP1 + SP2 is upto date: crash on exit
    here I found a computer with Vista licence
    which we use downgraded to XP
Only tried under condition 2): you can get a small number of succesive
successful terminations by placing into the shutdown code of
src/gui/main.cpp either of
a) SetProcessPriorityBoost(GetCurrentProcess(), TRUE); i.e. disabling it
b) call_core->reference (), possibly delaying shutdown of Ekiga's opal 
component.
If Ekiga was killed or terminated by the b) hack quite frequently a
subsequent attempt to register with ekiga.net fails.

Now the details! I have preparared an archive at 
http://wwwuser.gwdg.de/~mrickma/ekiga/vista-bug-logs.tar.gz (email to 
the list was bounced) with my attempts.
ekiga-stderr-not.txt, ekiga-stderr-yes.txt and the try... folders are 
from a type 2) installation. They are really from a Vista computer and 
not from XP as the logs say. I am absolutely shure that ptlib's 
recognition is wrong here because on my daughter's computer I used her 
account. Dir vistasp2 is from a type 4) installation and xp-crash from 
my XP-SP2 at home.
ekiga-stderr-not.txt, ekiga-stderr-yes.txt show the difference between 
the standard stuck and the priority changed (hack a)) behaviour of ekiga 
stable. All the other attempts are free from any hack. As I did not have 
the debugbreak running at that time I used for the try...s a break in 
ptlib/msos/win32.cxx, i.e. the C-library cleanup of Ekiga's GnomeMeeting 
PProcess-inheritance, and got mostly atypical performance. The only 
attempt which typically got stuck is try3. vistasp2 is from  Vista-SP2, 
it always crashes. xp-crash shows that a similar crash can also be 
elicited on a usually sane behaving OS, when the break is set before the 
ptlib housekeeper is deleted.

A quick trial with yesterday's HEADS of Ekiga, Opal and Ptlib on type 2) 
also got stuck. Fair to say that above problems without the ones where I 
set unnatural break points do not exist under Windows 7 RC.

I am a bit puzzled at the moment and hope that the material is 
sufficient to get some help.
Michael