After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 586913 - Ekiga freezes (alsa/pulse involved) after pressing hang up button
Ekiga freezes (alsa/pulse involved) after pressing hang up button
Status: RESOLVED INCOMPLETE
Product: ekiga
Classification: Applications
Component: Engine
3.2.x
Other All
: Normal critical
: ---
Assigned To: Ekiga maintainers
Ekiga maintainers
: 543748 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-06-25 06:08 UTC by dd
Modified: 2013-02-10 19:49 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
stack backtrace (106.34 KB, text/plain)
2009-06-25 06:30 UTC, dd
Details
SISSEGV (26.03 KB, text/plain)
2009-08-25 23:00 UTC, dd
Details
freeze (29.47 KB, text/plain)
2009-08-25 23:00 UTC, dd
Details
Output of ekiga -d 4 (23.35 KB, application/gzip)
2010-02-11 14:44 UTC, mu
Details
Output of gdb ekiga (1004 bytes, application/gzip)
2010-02-11 14:46 UTC, mu
Details
Output of gdb (13.89 KB, application/gzip)
2010-02-12 08:31 UTC, mu
Details
Output of gdb (4.09 KB, application/gzip)
2010-02-12 08:33 UTC, mu
Details

Description dd 2009-06-25 06:08:58 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
---
Comment 1 dd 2009-06-25 06:30:27 UTC
Created attachment 137351 [details]
stack backtrace
Comment 2 Eugen Dedu 2009-06-25 07:48:37 UTC
There is no stack backrace in your attachment, I do not know why.  Please retry.
Comment 3 dd 2009-06-25 08:00:00 UTC
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.
---
Comment 4 Eugen Dedu 2009-06-25 08:10:28 UTC
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.
Comment 5 dd 2009-06-25 10:01:29 UTC
Ok, thanks
Comment 6 Eugen Dedu 2009-07-07 21:07:23 UTC
3.2.5 has been released, could you test please?
Comment 7 dd 2009-07-08 05:40:08 UTC
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.
Comment 8 dd 2009-07-08 05:48:20 UTC
And where I can get 3.2.5 sources? ;)
http://ekiga.org/index.php?rub=5
Comment 9 Eugen Dedu 2009-07-08 06:12:16 UTC
The site will be updated shortly.

In a few days it will appear on debian too.
Comment 10 dd 2009-07-08 06:17:55 UTC
Good, thank you for your work.
Comment 11 Eugen Dedu 2009-07-24 17:47:51 UTC
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?
Comment 12 Jesper Pedersen 2009-07-26 14:36:39 UTC
This doesn't appear on Fedora 11 using stable branch 3.2 (20090726).
Comment 13 dd 2009-08-19 11:59:02 UTC
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
Comment 14 Eugen Dedu 2009-08-21 11:19:53 UTC
Zaphod, could you retry doing a gdb stacktrace?  We cannot know where the crash happens...
Comment 15 Jeremy Nickurak 2009-08-25 15:54:57 UTC
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?
Comment 16 Jeremy Nickurak 2009-08-25 15:56:11 UTC
*** Bug 543748 has been marked as a duplicate of this bug. ***
Comment 17 Damien Sandras 2009-08-25 16:03:58 UTC
I have the feeling it has been fixed in OPAL.
Comment 18 Jeremy Nickurak 2009-08-25 16:15:25 UTC
In what version of opal? Is there a particular version people should be testing to see if that change affected this issue?
Comment 19 Eugen Dedu 2009-08-25 19:35:07 UTC
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.
Comment 20 Eugen Dedu 2009-08-25 19:36:01 UTC
Jeremy, when it freezes, type ctrl-c in gdb, afterwards thread apply all bt and send us the result.
Comment 21 dd 2009-08-25 22:59:32 UTC
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.
Comment 22 dd 2009-08-25 23:00:18 UTC
Created attachment 141704 [details]
SISSEGV
Comment 23 dd 2009-08-25 23:00:47 UTC
Created attachment 141705 [details]
freeze
Comment 24 Eugen Dedu 2009-08-26 08:37:07 UTC
The SIGSEGV has been fixed sometime after 3.2.5:
  • #0 vtable for std::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >
  • #1 SIP_PDU::Write
    at /usr/include/ptlib/psync.h line 103

Comment 25 Eugen Dedu 2009-08-27 13:33:54 UTC
(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?
Comment 26 Yannick 2009-08-29 11:01:33 UTC
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
Comment 27 Yannick 2009-08-29 12:25:45 UTC
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
Comment 28 Damien Sandras 2009-08-29 13:12:00 UTC
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 ?
Comment 29 Yannick 2009-08-29 15:45:49 UTC
He does: "The freeze still happens even if I run ekiga with pasuspender."
Comment 30 Damien Sandras 2009-08-29 17:09:44 UTC
Please ask him a new bt. Does pasuspender really 'kill' pa ?
Comment 31 Yannick 2009-08-30 11:07:08 UTC
Hi Damien,

Here is the bt without pulse audio (for sure):
http://launchpadlibrarian.net/31005840/gdb-ekiga-nopulse.txt
Comment 32 Yannick 2009-08-30 11:26:17 UTC
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...
Comment 33 Yannick 2009-08-30 11:52:00 UTC
BTW, the last bt has debug symbols in it...
Comment 34 Yannick 2009-08-30 21:56:22 UTC
Damien,

This bt is with pulseaudio deamon uninstalled, thus should be ok:
http://launchpadlibrarian.net/31023901/gdb-ekiga-nopulse.txt

Best regards,
Yannick
Comment 35 Damien Sandras 2009-08-31 05:57:40 UTC
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 ?
Comment 36 Eugen Dedu 2009-08-31 15:57:57 UTC
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).
Comment 37 Yannick 2009-09-01 20:23:20 UTC
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
Comment 38 Yannick 2009-09-01 20:25:06 UTC
An idea: can it be related to mono versus stereo recording? I've seen recently ekiga can only use mono recording...
Comment 39 Damien Sandras 2009-09-13 15:39:34 UTC
Can the reporter try without sound events at all?
I have the feeling our friend portaudio strikes again.
Comment 40 Eugene Kanter 2009-12-10 17:34:01 UTC
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?
Comment 41 Eugen Dedu 2010-01-11 22:32:36 UTC
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
Comment 42 mu 2010-02-11 14:44:23 UTC
Created attachment 153533 [details]
Output of ekiga -d 4
Comment 43 mu 2010-02-11 14:46:22 UTC
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.
Comment 44 mu 2010-02-11 14:54:56 UTC
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.
Comment 45 mu 2010-02-11 15:16:25 UTC
(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.
Comment 46 Eugen Dedu 2010-02-11 15:19:39 UTC
Yes, please fill a new bug report and tell what ekiga version you use.

Even if it can take time to fix it...
Comment 47 mu 2010-02-12 08:31:00 UTC
Created attachment 153606 [details]
Output of gdb

In the previous, I did not "thread apply all bt"
Comment 48 mu 2010-02-12 08:33:33 UTC
Created attachment 153607 [details]
Output of gdb
Comment 49 Snark 2010-03-01 06:02:49 UTC
It does look pretty bad... have you tried disabling not only the sound events, but pulseaudio itself?
Comment 50 Tobias Mueller 2010-04-16 14:18:56 UTC
mu: ping.
Comment 51 mu 2010-05-06 08:35:41 UTC
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).
Comment 52 Eugen Dedu 2010-05-06 11:06:04 UTC
Well, closing the bug then.
Comment 53 Jeremy Nickurak 2010-05-26 19:05:15 UTC
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.
Comment 54 Eugen Dedu 2011-01-28 11:31:34 UTC
Let's shake this thread.  In the stack trace I see this:

Hilo 24 (Thread 0x7fffce0e9910 (LWP 8571)):
  • #0 __pthread_mutex_unlock_full
    from /lib/libpthread.so.0
  • #1 pa_mutex_unlock
    from /usr/lib/libpulsecommon-0.9.19.so
  • #2 ??
    from /usr/lib/alsa-lib/libasound_module_pcm_pulse.so
  • #3 ??
    from /usr/lib/libasound.so.2
  • #4 ??
    from /usr/lib/libasound.so.2
  • #5 ??
    from /usr/lib/libasound.so.2
  • #6 ??
    from /usr/lib/libasound.so.2
  • #7 PSoundChannelALSA::Read
    at sound_alsa.cxx line 448
  • #0 poll
    from /lib/libc.so.6
  • #1 ??
    from /usr/lib/libasound.so.2
  • #2 ??
    from /usr/lib/libasound.so.2
  • #3 ??
    from /usr/lib/libasound.so.2
  • #4 PSoundChannelALSA::Write
    at sound_alsa.cxx line 398

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?
Comment 55 Eugen Dedu 2012-10-21 10:19:41 UTC
Does this bug still appear with ekiga >= 3.3.90?  If yes, please post a new -d 4 output.
Comment 56 Tobias Mueller 2013-02-10 19:49:08 UTC
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!