Re: [Ekiga-devel-list] 100% cpu?

I have a little bit more data.

It seems to only do this thing, of hitting 100% cpu usage, after I get this message on the console:

*** PULSEAUDIO: Unable to create stream.
Cannot set parameters Input/output error

It turns out that the new ubuntu that I've upgraded to has PulseAudio as its default sound server. Ekiga doesn't support pulseaudio natively.

Also: I ran ekiga through gdb and interrupted when it was hitting 100% cpu, so that I could look at a backtrace. I got a couple of different answers, such as:

This one, I got when ekiga was so far gone that I could not choose "quit" from the "call" menu.

#0  0x00002b366a37bc76 in poll () from /lib/
#1  0x00002b36680d2366 in ?? () from /usr/lib/
#2 0x00002b36680d27d7 in g_main_loop_run () from /usr/lib/
#3  0x00002b3664ae1f03 in gtk_main () from /usr/lib/
#4  0x000000000044259e in main (argc=1, argv=0x7fff47746728,
     envp=<value optimized out>) at gui/main.cpp:4713

Somebody is doing some polling, but I can't seem to get more information than that.

My theory is that this is not a bug in ekiga, but is instead a bug in the way that non-native pulseaudio programs interact with pulseaudio in the latest ubuntu.

The bug could be worked around in ekiga by making it support pulseaudio natively, but could only be fixed in those other packages.

That's my theory.

Here's a backtrace I got another time. This one, I got after I chose "quit" from the "call" menu, which I did after it started hitting 100% cpu. The window disappeared, but the little phone icon remained in the notification area.

#0  0x00002b5eeef02b99 in pthread_cond_wait@@GLIBC_2.3.2 ()
    from /lib/
#1 0x00002b5eede9faab in PSyncPoint::Wait () from /usr/lib/
#2  0x00002b5eee58f839 in OpalManager::ClearAllCalls ()
    from /usr/lib/
#3  0x000000000045a177 in GMManager::Exit (this=0x7600a4)
     at endpoints/manager.cpp:154
#4  0x0000000000456775 in GnomeMeeting::RemoveManager (this=0x6cd720)
     at endpoints/ekiga.cpp:561
#5  0x0000000000456a8c in GnomeMeeting::Exit (this=0x7600a4)
     at endpoints/ekiga.cpp:164
#6  0x00000000004425b0 in main (argc=1, argv=0x7fffc2142128,
     envp=<value optimized out>) at gui/main.cpp:4716

Deadlock?  A live one?

Here's another backtrace. This one I got when I couldn't hit "call > quit".

#0  0x00002b5f311d4991 in sem_wait () from /lib/
#1 0x00002b5f3017055f in PSemaphore::Wait () from /usr/lib/
#2  0x00002b5f3018eb14 in PSafeObject::LockReadWrite ()
    from /usr/lib/
#3  0x00002b5f3018efc5 in PSafePtrBase::EnterSafetyMode ()
    from /usr/lib/
#4  0x00002b5f3018f7d8 in PSafePtrBase::PSafePtrBase ()
    from /usr/lib/
#5  0x00002b5f3085f7da in OpalManager::ClearAllCalls ()
    from /usr/lib/
#6  0x0000000000456c31 in GnomeMeeting::Disconnect (this=0x6cd720,
     reason=OpalConnection::EndedByLocalUser) at endpoints/ekiga.cpp:138
#7  0x00000000004363c3 in connect_button_clicked_cb (widget=0xc56810,
     data=<value optimized out>) at gui/callbacks.cpp:418
#8 0x00002b5f2f111bcf in g_closure_invoke () from /usr/lib/
#9  0x00002b5f2f1256bc in ?? () from /usr/lib/
#10 0x00002b5f2f1270d5 in g_signal_emit_valist ()
    from /usr/lib/
#11 0x00002b5f2f127483 in g_signal_emit () from /usr/lib/
#12 0x00002b5f2c2f3b99 in ?? () from /usr/lib/
#13 0x00002b5f2c3b987f in ?? () from /usr/lib/
#14 0x00002b5f2f111bcf in g_closure_invoke () from /usr/lib/
#15 0x00002b5f2f125aa8 in ?? () from /usr/lib/
---Type <return> to continue, or q <return> to quit---
#16 0x00002b5f2f126de6 in g_signal_emit_valist ()
    from /usr/lib/
#17 0x00002b5f2f127483 in g_signal_emit () from /usr/lib/
#18 0x00002b5f2c4c0e55 in ?? () from /usr/lib/
#19 0x00002b5f2c3b2b92 in gtk_propagate_event ()
    from /usr/lib/
#20 0x00002b5f2c3b3b35 in gtk_main_do_event ()
    from /usr/lib/
#21 0x00002b5f2c88758c in ?? () from /usr/lib/
#22 0x00002b5f2f9a1262 in g_main_context_dispatch ()
    from /usr/lib/
#23 0x00002b5f2f9a4516 in ?? () from /usr/lib/
#24 0x00002b5f2f9a47d7 in g_main_loop_run () from /usr/lib/
#25 0x00002b5f2c3b3f03 in gtk_main () from /usr/lib/
#26 0x000000000044259e in main (argc=1, argv=0x7fff7fe74e58,
     envp=<value optimized out>) at gui/main.cpp:4713

Finally, it seems that I did successfully compile it with gprof output, but the gmon.out file is only created if the program quits normally (or abnormally), and not if I have to kill it. In the past, I have been able to quit the program normally, even after it hits 100% cpu, but lately I've had to kill it, so the gmon.out is never created.

That's what I've got.

Okay, thanks.

On Sat, 28 Jun 2008, Ryan Hughes wrote:

Hi. (sorry for cross-post, I didn't know which list was the one to post this question to -- devel or users).

I've got ekiga 2.0.12.

Whenever I run it, it ends up taking up 95-99% of the CPU and not working. Sometimes it hangs when trying to connect to my sip account. Sometimes it hangs when trying to make a call. Sometimes it gets partway through a call before hanging. When it hangs in the middle of a call, I suddenly stop receiving audio.

However, even when it's at 99% cpu, it doesn't seem to become unresponsive. I can click the buttons and enter things into the address bar. I can open up the preferences screen or the account screen. I can quit it just fine. It just won't make calls or connect.

What should I be looking at for more info, or what can I do about this?

I tried to compile it with profiling to see what function it's stalling in, but I don't seem to know how to do that. I used this configure command:

./configure --prefix=/opt/ekiga CFLAGS="-g -pg"

However, when I run ekiga, no "gmon.out" file is produced. So if that's going to be the thing I need, then I'll need some help generating it.

Ekiga-devel-list mailing list
Ekiga-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]