[pulseaudio-discuss] Some issues with 0.9.16.

[Lennart Poettering]

On Mon, 31.08.09 17:00, Colin Guthrie (gmane at colin.guthr.ie) wrote:

>>>>   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.
>
> I spoke to soon. This seems to be related to some alsa bug. Here is the  
> output in case this situation can be handled better in the event of this  
> bug happening:

Uh. mlock() freezing is an memory management problem. It has as little
to do with alsa as it has with inotify.

mlock() is supposed to be a relatively fast system call. i.e. it
should block until all the pages asked for are read back from swap. If
it freezes for you something really bad is going on.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4