'Twas brillig, and Lennart Poettering at 28/08/09 15:39 did gyre and gimble: >> 3) I'm also seeing quite regularly a deadlock in pulse. This one is >> quite serious as it obviously freezes the display of most libcanberra >> apps :s See attached pulse-deadlock.txt > >> #0 0x00007f706ab57ea7 in mlock () from /lib64/libc.so.6 >> #1 0x00007f706e2ef0d2 in pa_will_need (p=0xc300c300c300c3, l=<value optimized out>) at pulsecore/core-util.c:2140 >> #2 0x00007f706e2fdbea in pa_memchunk_will_need (c=0x23cf0f8) at pulsecore/memchunk.c:88 >> #3 0x00007f706e2fccb9 in pa_memblockq_willneed (bq=<value optimized out>) at pulsecore/memblockq.c:914 > > [...] > >> 4 Thread 0x7f706a86b910 (LWP 9012) 0x00007f706ab51a47 in ppoll () from /lib64/libc.so.6 >> 3 Thread 0x7f70648f4910 (LWP 9016) 0x00007f706ab51a47 in ppoll () from /lib64/libc.so.6 >> 2 Thread 0x7f70640f3910 (LWP 9149) 0x00007f706ab51a47 in ppoll () from /lib64/libc.so.6 >> * 1 Thread 0x7f706ebba6f0 (LWP 8899) 0x00007f706ab57ea7 in mlock () from /lib64/libc.so.6 > > The IO threads are hanging in ppoll(), and are hence not > deadlocked. The main thread hangs in mlock(). Which is a fucntion that > locks memory into RAM. We use it as a dirty hack for making sure > cached samples are swapped back into RAM before we ask the IO threads > to play them. Normally, mlock() should just swap things in and lock > them. We then immediately call munlock(). If this freezes for you then > there is something really wrong with your kernel. I have not seen this > issue before. This seems be be behaving better with a new kernel... not had the problem again so far. I think the rc8 had some messed up inotify stuff which may explain it. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
