In ubuntu, Pulseaudio locks memory /dev/shm, jack problems

[Pablo]

Hi,

Many users with non-bleeding-edge computers, typically Pentium with 512 MB RAM and cheap integrated audio card try to use jack and linux audio programs. However, they sometimes get stuck with the problem described in the subject, resulting in jack failure and generally, weird behaviour.

See bug reports:

http://pulseaudio.org/ticket/806
and
https://bugs.launchpad.net/ubuntu/+sour ... bug/491329

I have recently helped two people. I asked them to show the output of:

ls -lah /dev/shm

And, if there are several pulse-sh-xxxxxxx or similar, I told them to do:

sudo rm /dev/shm/pulse*

This has been the case and has solved the problem in 100% of the cases (2 out of 2).

I have tried to reproduce the problem by repeatedly killing-starting pulseaudio and some clients and I have achieved 4 different pulse-shm files of 65 MB each. From Lennart's comments, I have understood that this doesn't mean that pulseaudio has locked 260 MB but he does not know what the problem is, probably ubuntu's and he says please show "du -ch /dev/shm" but the thread ends there.

On the other hand, in the launchpad bug, Emmet Hikory seems to recognize that the problem is in ubuntu's side, not pulseadio. But the importance is set to low and it is not to be solved in the stable release (lucid) but maybe in a future release

Some results in my computer:

pablo@desktop:~$ ls -lah /dev/shm
total 88K
drwxrwxrwt 2 root root 80 2010-07-15 16:27 .
drwxr-xr-x 15 root root 4,0K 2010-07-15 10:37 ..
-r-------- 1 pablo pablo 65M 2010-07-15 16:27 pulse-shm-3036937919
-r-------- 1 pablo pablo 65M 2010-07-15 16:27 pulse-shm-4075230858
pablo@desktop:~$ du -ch /dev/shm
88K /dev/shm
88K total

This does not seem incorrect, does it?

However, I try and try and some minutes later, I get:

pablo@desktop:~$ ls -lah /dev/shm
total 100K
drwxrwxrwt 2 root root 100 2010-07-15 17:04 .
drwxr-xr-x 15 root root 4,0K 2010-07-15 10:37 ..
-r-------- 1 pablo pablo 65M 2010-07-15 17:04 pulse-shm-2410175826
-r-------- 1 pablo pablo 65M 2010-07-15 17:04 pulse-shm-3901913164
-r-------- 1 pablo pablo 65M 2010-07-15 17:04 pulse-shm-4110520913
pablo@desktop:~$ du -ch /dev/shm
100K /dev/shm
100K total

which I don't know it is OK or not.

pablo@desktop:~$ ls -lah /dev/shm
total 300K
drwxrwxrwt 2 root root 120 2010-07-15 17:08 .
drwxr-xr-x 15 root root 4,0K 2010-07-15 10:37 ..
-r-------- 1 pablo pablo 65M 2010-07-15 17:08 pulse-shm-1055196772
-r-------- 1 pablo pablo 65M 2010-07-15 17:08 pulse-shm-245528451
-r-------- 1 pablo pablo 65M 2010-07-15 17:08 pulse-shm-2946823272
-r-------- 1 pablo pablo 65M 2010-07-15 17:08 pulse-shm-305513505
pablo@desktop:~$ du -ch /dev/shm
300K /dev/shm
300K total

and, seconds later

pablo@desktop:~$ du -ch /dev/shm
324K /dev/shm
324K total

...

More test followed but I couldn't catch a huge amount of memory in the output of du. In addition, I have 2 GB of RAM, so I cannot properly reproduce the bug.

However, I asked one of the people who I helped to please give the output of :

du -ch /dev/shm

when jack got stuck again. He has 512 MB of RAM and he is very badly bitten by this bug.

Here the results on his machine:

$ ls -lah /dev/shm
total 65M
drwxrwxrwt 3 root root 200 2010-07-17 18:56 .
drwxr-xr-x 16 root root 4,2K 2010-07-17 16:30 ..
drwx------ 3 alf alf 60 2010-07-17 18:51 jack-1000
-r-------- 1 alf alf 65M 2010-07-17 18:54 pulse-shm-141142195
-r-------- 1 alf alf 65M 2010-07-17 18:56 pulse-shm-161183459
-r-------- 1 alf alf 65M 2010-07-17 18:55 pulse-shm-2086565724
-r-------- 1 alf alf 65M 2010-07-17 18:10 pulse-shm-2383684886
-r-------- 1 alf alf 65M 2010-07-17 18:54 pulse-shm-3169169895
-r-------- 1 alf alf 65M 2010-07-17 18:54 pulse-shm-3519518472
-r-------- 1 alf alf 65M 2010-07-17 18:54 pulse-shm-825331528

$ du -ch /dev/shm
0 /dev/shm/jack-1000/default
0 /dev/shm/jack-1000
65M /dev/shm
65M total

Now, I will tell him to kill pulseaudio at boot and do the trick to avoid respawn but I thought I would comment here, as raboof is following this bug.

Cheers! Pablo

[spm_gl]

It would be interesting to see the behaviour on a different distro, if it is an ubuntu bug. But hardly anyone else uses pulseaudio.

[StudioDave]

It would be interesting to see the behaviour on a different distro, if it is an ubuntu bug. But hardly anyone else uses pulseaudio.

Hardly anyone here, you mean. I suspect that many users are happy enough with it. I decided to roll with it when I installed Ubuntu 10.04 on my laptop. I've had no particular difficulties with it yet, it gets out of the way nicely when I run JACK, and it doesn't appear to be mucking up anything else in my system.

And lest anyone believe I'm uncritical of Ubuntu and PA :

http://www.linuxjournal.com/content/jud ... studio-904

By comparison Lucid has been an almost completely satisfactory experience.

Best,

dp

[raboof]

Emmet Hikory seems to recognize that the problem is in ubuntu's side, not pulseadio. But the importance is set to low and it is not to be solved in the stable release (lucid) but maybe in a future release

Worse: it's marked as 'duplicate', and the 'parent' bug is marked 'wontfix'. Unless we come up with more pressing evidence that there's really something wrong here, the Ubuntu folks are unlikely to work on this issue.

I have 2 GB of RAM, so I cannot properly reproduce the bug.

IIRC I could reproduce it by simply sticking a big file in /dev/shm (with 'dd' i think).

[Pablo]

Code: Select all

Worse: it's marked as 'duplicate', and the 'parent' bug is marked 'wontfix'. Unless we come up with more pressing evidence that there's really something wrong here, the Ubuntu folks are unlikely to work on this issue.

Ahm. And zettberlin is right:

"if this error occurs, one cannot hope to run jackd on Ubuntu without getting more RAM"

I wish ubuntu devs and pulseaudio (and gnome?) devs collaborate to get rid of this nasty bug.

Cheers! Pablo

[spm_gl]

Could it be a problem with the files having read-only rights?

[raboof]

Ha, I'm starting to remember - I mostly forgot about this bug .

Afaics, there's a couple of things going on here:

• 1) somehow old unused pulseaudio stuff heaps up in /dev/shm
  2) libasound calls pulseaudio even if pulse is not running. Presumably not a problem because pulse will quickly determine it's not running and get out of the way
  3) but in this case it does cause memory allocation, and because /dev/shm is full, the kernel sends a SIGBUS to the process, and it dies
  4) the user is left wondering wtf was going on

As for progress on these issues:

• 1) it's not clear how/why this happens, and whether it happens on other platforms than ubuntu, too. Needs more investigation.
  2) probably unavoidable (and should really be no problem when (1) is fixed)
  3) probably unavoidable (and should really be no problem when (1) is fixed)
  4) as pulseaudio can't catch SIGBUS, whoever sends it (probably the kernel?) should provide better logging when this situation occurs.

As for (1), i guess when pulseaudio is stopped, it should clean up after itself. Can anyone reproduce a scenario where it doesn't?

[raboof]

Hmm. On Debian, even when manually filling up /dev/shm, I can't seem to reproduce this issue. It seems either (2) or (3) isn't happening.