Hi Michael, First of all, thanks for the continuous work. I think your efforts will lead to a more stable Ekiga.
After examinating the logs, I think we can first try fixing the crash. We can fix the deadlock after. When I look at try1-segfault and try2-segfault, I can see the crash is similar and happens in PTLIB. I'll ask Robert if he has an idea. It is a part of the code he knows very well. Le jeudi 30 juillet 2009 à 19:46 +0200, Michael Rickmann a écrit : > 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 > > _______________________________________________ > Ekiga-devel-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/ekiga-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ Be IP : http://www.beip.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:[email protected] _______________________________________________ Ekiga-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
