[pulseaudio-discuss] Some issues with 0.9.16.

[Lennart Poettering]

On Fri, 28.08.09 09:27, Colin Guthrie (gmane at colin.guthr.ie) wrote:

> Hi,
>
> Just doing the usual round of testing :)
>
> Three things:
>
> 1) So far I've got two people reporting that the latest batch of updates  
> have caused CPU usage problems and choppy (or no audio) so I think there  
> is a bit of a problem somewhere in that regard). While more detail is on  
> the mailing list, this is probably the bug we'll use to track it:
> https://qa.mandriva.com/show_bug.cgi?id=53236
>
> I tried a test build disabling the watermark reset commit and the MMX  
> optimisations but to no avail.
>
> I guess I'll need to do some kind of remote bisect unless anyone has any  
> bright ideas?

Candidates to check out are probably
050a3a99e1d151b4f55c89f82073ef33f3399646,
80c693730365c1a375a5c0e781f38e7f165b37bf,
c1b6a87b27b569cda135da05b53cc98aa9ca37cb and of coruse the SSE/MMX stuff.

> 2) I'm getting an assert being hit quite often. See attached  
> pulse-assert.txt

There's some bad memory access going on, but Iam having a hard time
tracking that down without valgrind as valgrind is useless on rawhide
right now. So I am waiting for vg to get fixed before fixing this.

> 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. 

Lennart

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