GNOME Bugzilla – Bug 404155
Ekiga will not start with accessibility enabled
Last modified: 2007-09-13 03:06:16 UTC
The following problem crops up while trying to start ekiga with accessibility enabled on the latest fully up to date ubuntu feisty pre-release with the latest gnome 2.17 milestone bits. 1. Login and enable assistive technology support. 2. Log out and back in. 3. Attempt to start ekiga. At this point ekiga briefly appears and then disappears and does not start. It does not matter if an assistive technology such as orca is running or not. If assistive technology is not enabled ekiga starts normally.
Mike, thanks for the report. Can you provide more information, such as possible <stderr> outputs or, if it's a crash, a full backtrace? I don't have the exact library versions for the GNOME 2.17 milestone, so it can also be a buggy ATK/similar. J.
It seems that it's not so much that it crashes as it is that it never fully launches. If I launch ekiga from a terminal window, the process starts (shows up in the list of processes and stays there until I forcefully kill it) and that's it.
Note, if you are going to test this on ubuntu feisty you first need to build and install libgail-gnome as it is currently missing from feisty. I also tested this with the latest tarball release of gail and then gail from trunk. It seems as though this can also be reproduced with a daily live cd from cdimages.ubuntu.com
Hm. Will test a live-cd the other day. It really sounds like some Ekiga-external deadlock :/ Can you Ctrl-C it and provide a gdb backtrace? We should see in which circumstances it hangs then. J.
I think I got the problem. In src/gui/main.cpp, ekiga calls gdk_threads_init(); ... gnome_program_init ... gdk_threads_enter(); Note it calls gnome_program_init after the gdk_threads_init and before the gdk_threads_enter. gnome_program_init will init atk-bridge in which we call gdk_threads_leave/enter to prevent deadlock. So I think it is better that a program calls gdk_threads_enter right after gdk_threads_init.
Indeed, sounds fairly reasonable. Any further comments, Julien, Damien? J.
If you want to commit the patch to fix this I'll gladdly build and test ekiga for any other accessibility problems before the next tarball release. Not trying to push I just have some time over the next few days and thought I'd do some ekiga testing as well.
I saw Damien just tagged 2_0_5 in SVN :/ @Damien: I'll fix gnome-2-14 branch, can we wait another few days? Or is that for 2.0.6 then? @Mike: Thank you very much for this offer. You're having something I don't have at the moment (okay, I have, between 5:30 am and 7:00 am...): time ;-) J.
Okay, committed to svn into all active branches: HEAD [trunk] H_Release [branch] gnome-2-14 [branch] (ignored the current EKIGA_2_0_5 tag, in worst case it goes to 2.0.6!) J. PS: I can't confirm it doesn't deadlock anymore, as it did not deadlock here before. Please close this bug when the fix works for you, thanks.
This sounds like Launchpad bug: https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/88355 Is this the same bug?
The bug you said seems like a duplicate of #329454. If we can get the full trace included all the threads, it would be better.
Thanks Jan. I will close the bug after our patch for #329454 finished and all works fine.
This bug is registered as the upstream bug report for Launchpad bug: https://bugs.launchpad.net/gnomemeeting/+bug/88355