jackd cannot be started in realtime mode on Karmic if there is not enough free space in /dev/shm

Bug #491329 reported by Holger Arnold
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
jack-audio-connection-kit (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

When trying to start jackd in realtime mode with memory locking enabled, at least on my system, it crashes with a "Bus error" without printing any useful error message. What happens seems to be the following:

1. Ubuntu mounts a tmpfs file system in /dev/shm with a size of 50% of the main memory size. My system has only 512MB RAM, so my /dev/shm is 256MB.
2. /dev/shm is also used by Pulseaudio, which seems to allocate ~64MB for every client. On my system this means that most of the time there is no free space in /dev/shm. Moreover, even after shutting down Pulseaudio, there are pulse-shm-* files left in /dev/shm.
3. When started in realtime mode with memory locking enabled, jackd attempts to allocate ~130MB shared memory without checking for free space. This fails and jackd crashes with a bus error.

I don't know exactly how the /dev/shm file system works or how Pulseaudio uses it, but the following solves the problem:

1. Make shure that Pulseaudio is not running. I use the Fluxbox WM for audio, so when I kill Pulseaudio, it is not automatically restarted; I don't know how this can be done when running Gnome.
2. Clean up /dev/shm by deleting the files left over by Pulseaudio.
3. Start jackd in realtime mode with memory locking enabled.

I would expect the following behavior:

1. jackd should tell the user that there is not enough shared memory available and shut down cleanly instead of crashing.
2. There should be no files left over by Pulseaudio when it is not running.

ProblemType: Bug
Architecture: i386
Date: Wed Dec 2 11:56:48 2009
DistroRelease: Ubuntu 9.10
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
Package: jackd 0.116.1-4ubuntu2
ProcEnviron:
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-15.50-generic
SourcePackage: jack-audio-connection-kit
Uname: Linux 2.6.31-15-generic i686

Revision history for this message
Holger Arnold (holgerarnold) wrote :
Revision history for this message
Jonas Norling (norling) wrote :

I experience what appears to be the same problem on my laptop with a USB sound device.

I'm running Karmic. Pulseaudio is enabled but the USB sound device is set to profile "Off" in the Sound Preferences GUI, so pulseaudio shouldn't try to use it (right?). Pulseaudio is allowed to manage the laptop's internal sound device, though.

Immediately after logging in, pulseaudio has created (around) five 65MB files in /dev/shm, but only a total of 224kB is actually allocated/used:

jonas@bruno:~$ ls -lsh /dev/shm/
total 224K
4.0K -rw-r----- 1 jonas jonas 4.0K 2009-12-25 13:20 mono.5866
 84K -r-------- 1 gdm gdm 65M 2009-12-25 13:20 pulse-shm-3132421645
 32K -r-------- 1 jonas jonas 65M 2009-12-25 13:22 pulse-shm-3183276808
 12K -r-------- 1 jonas jonas 65M 2009-12-25 13:20 pulse-shm-3321423159
 80K -r-------- 1 jonas jonas 65M 2009-12-25 13:22 pulse-shm-3424433770
 12K -r-------- 1 jonas jonas 65M 2009-12-25 13:20 pulse-shm-586544485

When I try to start jackd, pulseaudio starts to fill up its previously sparse files in /dev/shm. After a few seconds and a lot of swapping jackd exits with "Bus error" and my /dev/shm is completely filled:

jonas@bruno:~$ ls -lsh /dev/shm/
total 232M
   0 drwx------ 3 jonas jonas 60 2009-12-25 13:22 jack-1000
4.0K -rw-r----- 1 jonas jonas 4.0K 2009-12-25 13:20 mono.5866
 84K -r-------- 1 gdm gdm 65M 2009-12-25 13:20 pulse-shm-3132421645
 65M -r-------- 1 jonas jonas 65M 2009-12-25 13:22 pulse-shm-3183276808
 65M -r-------- 1 jonas jonas 65M 2009-12-25 13:20 pulse-shm-3321423159
 39M -r-------- 1 jonas jonas 65M 2009-12-25 13:22 pulse-shm-3424433770
   0 -r-------- 1 jonas jonas 65M 2009-12-25 13:22 pulse-shm-448440592
 65M -r-------- 1 jonas jonas 65M 2009-12-25 13:20 pulse-shm-586544485

All this happens only when I have "@audio - memlock unlimited" in my limits.conf (otherwise jackd says that it can't allocate memory, but seems to work happily anyway). Sometimes not enough pulseaudio clients are running to fill up /dev/shm and jackd will start fine. My preferred workaround is to start jackd on the console before logging in.

My system:
512MB RAM,
USB sound device: ESI U46XL
Ubuntu realtime kernel linux-image-rt 2.6.31.9.10
pulseaudio 1:0.9.19-0ubuntu4, jackd 0.116.1-4ubuntu2

Revision history for this message
Emmet Hikory (persia) wrote :

Thanks for the bug report. This is definitely an issue with the memory allocation check, but unlikely to be fixed in a stable release update, although it may be fixed in a future release. Running with memory locking enabled seems to be the least bad workaround, although a bit awkward.

Changed in jack-audio-connection-kit (Ubuntu):
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
raboof (arnouten) wrote :

Strange, JACK only appears to create some empty sockets and FIFO's in /dev/shm here, though it does start up in RT mode and shows 'JACK compiled with System V SHM support'.

Revision history for this message
raboof (arnouten) wrote :

I can reproduce it though. It looks like libasound calls some pulseaudio code, which is where the bus error occurs:

loading driver ..
apparent rate = 44100
creating alsa driver ... hw:0|hw:0|256|2|44100|0|0|nomon|swmeter|-|32bit
control device hw:0

Program received signal SIGBUS, Bus error.
pa_atomic_load () at ./pulsecore/atomic.h:57
57 ./pulsecore/atomic.h: No such file or directory.
        in ./pulsecore/atomic.h
(gdb) where
#0 pa_atomic_load () at ./pulsecore/atomic.h:57
#1 pa_shm_cleanup () at pulsecore/shm.c:370
#2 0x00e7dfed in pa_shm_create_rw (m=0x8086f18, size=67108864, shared=true, mode=448) at pulsecore/shm.c:109
#3 0x00e7024f in pa_mempool_new (shared=false, size=0) at pulsecore/memblock.c:731
#4 0x00d738a4 in pa_context_new_with_proplist (mainloop=0x807cca8, name=0xd19993 "Alsa hook", p=0x0) at pulse/context.c:199
#5 0x00d7398c in pa_context_new (mainloop=0x807cca8, name=0xd19993 "Alsa hook") at pulse/context.c:116
#6 0x00d1987d in conf_pulse_hook_load_if_running () from /usr/lib/alsa-lib/libasound_module_conf_pulse.so
#7 0x004e43d7 in ?? () from /usr/lib/libasound.so.2
#8 0x004e49c5 in snd_config_searcha_hooks () from /usr/lib/libasound.so.2
#9 0x004e4b14 in snd_config_searchva_hooks () from /usr/lib/libasound.so.2
#10 0x004e4caa in ?? () from /usr/lib/libasound.so.2
#11 0x004e4e7b in snd_config_search_definition () from /usr/lib/libasound.so.2
#12 0x004f2dbd in ?? () from /usr/lib/libasound.so.2
#13 0x00fa3de9 in ?? () from /usr/lib/jack/jack_alsa.so
#14 0x00fa615c in driver_initialize () from /usr/lib/jack/jack_alsa.so
#15 0x00dc1110 in jack_engine_load_driver () from /usr/lib/libjackserver.so.0

It's a bit odd that ALSA calls PulseAudio code at all, but if there's enough memory available this doesn't appear to be a problem.

Looks like when SHM memory is low, PulseAudio gets confused.

Revision history for this message
raboof (arnouten) wrote :
Revision history for this message
raboof (arnouten) wrote :

Another one:

loading driver ..
apparent rate = 44100
creating alsa driver ... hw:0|hw:0|256|2|44100|0|0|nomon|swmeter|-|32bit
control device hw:0

Program received signal SIGBUS, Bus error.
pa_shm_create_rw (m=0x8086f20, size=<value optimized out>, shared=true, mode=448) at pulsecore/shm.c:165
165 pulsecore/shm.c: No such file or directory.
        in pulsecore/shm.c
(gdb) where
#0 pa_shm_create_rw (m=0x8086f20, size=<value optimized out>, shared=true, mode=448) at pulsecore/shm.c:165
#1 0x0017424f in pa_mempool_new (shared=35, size=0) at pulsecore/memblock.c:731
#2 0x001208a4 in pa_context_new_with_proplist (mainloop=0x807ccb0, name=0x110993 "Alsa hook", p=0x0) at pulse/context.c:199
#3 0x0012098c in pa_context_new (mainloop=0x807ccb0, name=0x110993 "Alsa hook") at pulse/context.c:116
#4 0x0011087d in conf_pulse_hook_load_if_running () from /usr/lib/alsa-lib/libasound_module_conf_pulse.so

Submitted upstream at http://pulseaudio.org/ticket/806

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.