GNOME Bugzilla – Bug 586913
Ekiga freezes (alsa/pulse involved) after pressing hang up button
Last modified: 2013-02-10 19:49:08 UTC
Please describe the problem: Ekiga freeze after I press hang up button (cancel call) Sorry for my english. Steps to reproduce: 1. Run Ekiga 2. Call some number 3. Press hang up Actual results: Ekiga freeze Expected results: Does this happen every time? Yes Other information: Ubuntu 9.04 Linux zaphod 2.6.28-13-generic #44-Ubuntu SMP Tue Jun 2 07:55:09 UTC 2009 x86_64 GNU/Linux --- $ apt-cache policy ekiga ekiga: Установлен: 3.2.0-0ubuntu2 Кандидат: 3.2.0-0ubuntu2 Таблица версий: *** 3.2.0-0ubuntu2 0 500 http://ru.archive.ubuntu.com jaunty-updates/main Packages 100 /var/lib/dpkg/status 3.2.0-0ubuntu1 0 500 http://ru.archive.ubuntu.com jaunty/main Packages ---
Created attachment 137351 [details] stack backtrace
There is no stack backrace in your attachment, I do not know why. Please retry.
How can I do it? Ekiga freezed (don't crashed) and I killed process. --- Program terminated with signal SIGKILL, Killed. The program no longer exists. (gdb) (gdb) thread apply all bt No registers. ---
I also feel that this bug (hang when stopping cal) has been fixed in the stable branch, we could also wait a bit, until a new release appears. You could test then if the bug was indeed fixed or not.
Ok, thanks
3.2.5 has been released, could you test please?
Unfortunately building Ekiga from sources is not trivial (for me?), so I can not install version 3.2.5. I can't find binary Debian package, but I installed version 3.2.4+git20090705 from Launchpad PPA and in this version bug does not exist. On the other hand now I can not hear when calling on 500@ekiga.net. :) But now I am waiting build 3.2.5, and if nothing changed, I will open a new bug.
And where I can get 3.2.5 sources? ;) http://ekiga.org/index.php?rub=5
The site will be updated shortly. In a few days it will appear on debian too.
Good, thank you for your work.
Hi Zaphod, 3.2.5 is available on ubuntu (on debian too), https://launchpad.net/ubuntu/+source/ekiga, could you test if this bug still appears?
This doesn't appear on Fedora 11 using stable branch 3.2 (20090726).
Same error. $ apt-cache policy ekiga ekiga: Установлен: 3.2.5-1ubuntu1~jaunty0 Кандидат: 3.2.5-1ubuntu1~jaunty0 Таблица версий: *** 3.2.5-1ubuntu1~jaunty0 0 500 http://ppa.launchpad.net jaunty/main Packages 100 /var/lib/dpkg/status 3.2.0-0ubuntu2 0 500 http://archive.ubuntu.com jaunty-updates/main Packages 3.2.0-0ubuntu1 0 500 http://archive.ubuntu.com jaunty/main Packages
Zaphod, could you retry doing a gdb stacktrace? We cannot know where the crash happens...
Sounds like http://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/380046 to me. I can confirm having this issue with 3.2. Since it's a freeze, not a crash, I don't see how to get a stacktrace. What additional information would you like us to provide?
*** Bug 543748 has been marked as a duplicate of this bug. ***
I have the feeling it has been fixed in OPAL.
In what version of opal? Is there a particular version people should be testing to see if that change affected this issue?
3.2.5 fixed a issue for this. However, I see that the reporter still has it for 3.2.5 too, so we wait his stacktrace to see where the problem is. Jeremy, if you have it too, please install 3.2.5 and give us a stacktrace.
Jeremy, when it freezes, type ctrl-c in gdb, afterwards thread apply all bt and send us the result.
I've got to make a backtrace :) But the first time Ekiga crashed with segmentation fault. The second try Ekiga hangs as it should be. ;-) See attachments.
Created attachment 141704 [details] SISSEGV
Created attachment 141705 [details] freeze
The SIGSEGV has been fixed sometime after 3.2.5:
+ Trace 217145
(In reply to comment #23) > Created an attachment (id=141705) [details] > freeze Zaphod, we need more information. Do you have DNS problems? Is it 100% reproducible (crash or freeze)? Does it always appear on hang up? Please resend the output together with -d 4 output, such as: gdb --args ekiga -d 4 2>&1 | tee gdb.log Jeremy, could you also try the same thing?
Zaphod Beeblebrox, I've build some fresh deb for ubuntu jaunty with the current stable tree of Ekiga here: https://launchpad.net/~sevmek/+archive/ekiga-stable-prerelease Could you try it to check if Damien's feeling is right? Or do you still have the freeze? Best regards, Yannick
hum, seems we still have the freeze in stable branch: downstream report: https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/391976/comments/8 bt: http://launchpadlibrarian.net/30965839/gdb-ekiga.txt
For Yannick's bt: In thread 30, the AudioInputCore captures data (get_frame_data()), when doing so, it holds mutex core_mutex. In thread 1, the AudioInputCore is stopped (stop_stream()), when doing so, it holds mutex core_mutex. Thread 1 won't finish before thread 30 is finished. My suggestion would be that reading data blocks. I see the reporter is using pulseaudio. Does he have the same problem without pulseaudio ?
He does: "The freeze still happens even if I run ekiga with pasuspender."
Please ask him a new bt. Does pasuspender really 'kill' pa ?
Hi Damien, Here is the bt without pulse audio (for sure): http://launchpadlibrarian.net/31005840/gdb-ekiga-nopulse.txt
Damn! I was wrong, the last bt has pulseaudio. It keeps pop up even if you kill it explicitly... I'll try to find a way...
BTW, the last bt has debug symbols in it...
Damien, This bt is with pulseaudio deamon uninstalled, thus should be ok: http://launchpadlibrarian.net/31023901/gdb-ekiga-nopulse.txt Best regards, Yannick
I don't understand the deadlock and I wonder why this user has a 100% reproducable deadlock. The stream is closed, but it waits for the last frame to be read to be able to close the stream (there is a mutex). It block the UI. Why is it 100% reproducible on his machine ? Is he able to have a successful call ? Is he doing something special to reproduce the bug ? Julien, any idea ?
There has just been a fix for dns in opal http://opalvoip.svn.sourceforge.net/viewvc/opalvoip?view=rev&revision=23308, I do not know if it has anything to do with this bug (see comment #25).
From the reporter: "I've not been able to make a successful call yet. When I launch Ekiga, I can make a call to the echo test, I can hear the incoming voice, but I can't record my own. I then hang up and Ekiga hangs. However, I see that if I try recording something with Sound Recorder I get a similar situation (it hangs when I stop recording - also I notice that it's not registering any input). So I think this may be something to do with my sound input system maybe?" https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/391976/comments/19
An idea: can it be related to mono versus stereo recording? I've seen recently ekiga can only use mono recording...
Can the reporter try without sound events at all? I have the feeling our friend portaudio strikes again.
I have two Fedora 12 systems one with internal audio and second with external USB headset. The first one crashes on a hand up on a regular basis. I have core dump preserved. The one with USB audio hasn't crashed yes despite intensive use. The core dump show many missing debuginfo entries despite the fact that I ran debuginfo-install ekiga. What debuginfo should I add? Will submitting bug report using abrt-gui help?
Eugene, you need to install debug info not only for ekiga, but for ptlib and opal too. Is this the case? You need to send us the stack backtrace, as shown at http://wiki.ekiga.org/index.php/Debugging_Ekiga#How_to_get_a_stack_backtrace_from_a_crash
Created attachment 153533 [details] Output of ekiga -d 4
Created attachment 153534 [details] Output of gdb ekiga * Belongs to a different execution from the previous one * The first call I did did not freeze.
I have the same problem. It happens at least 75% of times. Not only me, my entire office, which uses Ubuntu, has the same problems (we recently had installed a new voip server). I am using Ubuntu 9.10. I have tried both the mainstream repository version (3.2.5) and sevmek repository (3.2.6). For the record, I am using pulseaudio. I left two attachments following the wiki instructions. They belongs to 2 different program execution. In the gdb trace, I managed to do a call without ekiga crashing. Please, ask me any info you need and I'll do my best to provide it.
(In reply to comment #39) > Can the reporter try without sound events at all? > I have the feeling our friend portaudio strikes again. I disallowed all sound events, one by one, in Edit -> Preferences and then General -> Sound Events (text may differ because I use the Spanish translation). The problem persists, apparently nothing changes. By the way, and uglier bug emerges. Each time I disallow one sound event, the program crashes. However, when run ekiga again, the event is unchecked. I have debug traces, but I don't know if I should fill a different bug, so you tell me.
Yes, please fill a new bug report and tell what ekiga version you use. Even if it can take time to fix it...
Created attachment 153606 [details] Output of gdb In the previous, I did not "thread apply all bt"
Created attachment 153607 [details] Output of gdb
It does look pretty bad... have you tried disabling not only the sound events, but pulseaudio itself?
mu: ping.
Sorry, Tobias, the email notification is not working for me :( I logged today to announce that in Ubuntu 10.04 the bug does not show himself. I am totally sure that it is a bug in pulseaudio, since I experienced similar problems in other application (allways when quitting the application, so it seems a problem with releasing sound resources).
Well, closing the bug then.
Pulseaudio's working fine. It's not crashing, it continues to send/recieve sound events, and playback correctly. It's likely an issue that ekiga's use of alsa is causing it to lock up when it sees pulseaudio's virtual alsa device, but that's not a problem in pulseaudio.
Let's shake this thread. In the stack trace I see this: Hilo 24 (Thread 0x7fffce0e9910 (LWP 8571)):
+ Trace 225738
Craig, is it possible that two threads read (PSoundChannelALSA::Read at sound_alsa.cxx:448) and write (PSoundChannelALSA::Write at sound_alsa.cxx:398) concurrently given that at the beginning of both functions there is "PWaitAndSignal m(device_mutex)"? Or could the stacktrace be unreliable?
Does this bug still appear with ekiga >= 3.3.90? If yes, please post a new -d 4 output.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!