GNOME Bugzilla – Bug 558524
Lockup after some hours of being idle
Last modified: 2009-07-27 12:12:30 UTC
Steps to reproduce: 1. It calls and works fine but if it is left idle for some time it locks up. Stack trace: Program received signal SIGINT, Interrupt. 0x000000364640dad4 in ?? () from /lib64/libpthread.so.0 (gdb) bt
+ Trace 208914
Other information: Fedora 10alpha / current Rawhide ekiga-3.0.1-2.fc10.x86_64 I do not guarantee the other versions exactly match the backtrace but it is mostly similiar (with some updates) to the versions listed in Bug 558495.
Can you provide a complete backtrace with thread apply all bt ?
As I run the default -O2 rpm build the variables dump is not much useful. Sure I could rebuild all the libraries with `-O0 -g' etc. but I just tried if the bug is not more obvious. (gdb) bt full
+ Trace 208960
The new backtrace is still unuseful, since it only shows one thread. Like I said a thread apply all bt is needed even if it does not show all debug symbols
Sorry, I did read it wrong (it did not show me it has threads before due to some other local problems). (gdb) info threads 11 Thread 0x7f6030f96950 (LWP 14112) 0x000000364640b2c9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 10 Thread 0x7f6030f55950 (LWP 14113) 0x000000364640b2c9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 9 Thread 0x7f6030f14950 (LWP 14114) 0x000000364640b2c9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 8 Thread 0x7f6030ed3950 (LWP 14115) 0x000000364640d2c1 in sem_wait () from /lib64/libpthread.so.0 7 Thread 0x7f6030e92950 (LWP 14116) 0x000000364640b54d in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 6 Thread 0x7f6030e51950 (LWP 14117) 0x000000364640d2c1 in sem_wait () from /lib64/libpthread.so.0 5 Thread 0x7f6030d46950 (LWP 14121) 0x00000036458dca86 in *__GI___poll (fds=0x2a2a700, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 4 Thread 0x7f6030345950 (LWP 14128) 0x00000036458dca86 in *__GI___poll (fds=0x2a2ae20, nfds=9, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 3 Thread 0x7f6030e10950 (LWP 14144) 0x000000364640b2c9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 2 Thread 0x7f6030dc8950 (LWP 14145) 0x00000036458dec62 in select () from /lib64/libc.so.6 * 1 Thread 0x7f6035c3f800 (LWP 14110) 0x000000364640dad4 in __lll_lock_wait () from /lib64/libpthread.so.0 (gdb) thread apply all bt
+ Trace 209198
Thread 1 (Thread 0x7f6035c3f800 (LWP 14110))
I suppose this is the same as the Write crash (recently fixed), since it is in the same code (publish) and only after some hours of being idle. Jan, please check with current svn/git or try the new 3.2.5 ekiga (which will appear very soon).
Jan, any news?
Running now ekiga-3.2.5-2.fc11 opal-3.6.4-2.fc11 ptlib-2.6.4-2.fc11 (x86_64) and after a day of idle it cannot call even <sip:500@ekiga.net>. It no longer crashes but the call hangs up immediately without getting connected. Simple restart of Ekiga makes <sip:500@ekiga.net> working. Running now with `-d 4' and going to post some results when it gets idle enough.
This is bug #579938, so we can close this bug about the lockup, is that right?
Bug #579938 is talking about broken reception of calls while calls originating works there. Anyway it can be considered a different bug I am going to post/follow-up so closing this one, thanks.
Note there's also bug #584676.