[pulseaudio-tickets] [PulseAudio] #806: Bus Errors when /dev/shm is (almost) full

[PulseAudio]

#806: Bus Errors when /dev/shm is (almost) full
----------------------+-----------------------------------------------------
  Reporter:  raboof   |       Owner:  lennart      
      Type:  defect   |      Status:  closed       
 Milestone:           |   Component:  core         
Resolution:  wontfix  |    Keywords:  bus crash shm
----------------------+-----------------------------------------------------

Comment(by lennart):

 Replying to [comment:3 raboof]:

 > I do think it would be good, if possible, to give the user some
 indication that this is what's going wrong. Just raising SIGBUS and
 leaving the user wondering what happened is rather puzzling.

 Well, that would mean we'd have to install a SIGBUS handler on the client
 side too, which as mentioned is messy, since signal handlers are per-
 process and hence only one library/module can install one and it better be
 the main application if any.

 > I don't quite understand what exactly causes the SIGBUS - is it possible
 to identify this situation beforehand, to show an error message somewhere
 before the SIGBUS is signalled? Or it this handled entirely at the kernel
 side of things?

 PA allocates an shm region of 64mb in /dev/shm per client and per server.
 That will only allocate 64mb of address space, but not back it up with
 actual RAM. This hence is very efficient, and doesn't cost a thing, and
 also allows overcommiting: even if you only have limited RAM around you
 can run a lot of clients and servers. Now, the first time PA actually
 writes something to that SHM memory it is backed up by real memory and the
 pages used will be subtracted from the free space in the /dev/shm file
 system. The SIGBUS now happens if PA writes to that SHM memory and there
 is actually no space on the /dev/shm filesystem available anymore. The SHM
 address space cannot be backed by RAM, and this all happened just because
 of a normal memory write. The kernel then only has the option to send a
 SIGBUS to the application because the memory access cannot be executed and
 try to terminate it that way.

 This is in no way different to normal anonymous memory allocation: you can
 malloc() lots of address space, and on the first write access it will
 actually be backed up. And then, finally -- unless the OOM killer kills
 you first -- when that memory cannot be backed anymore you'll be killed by
 SIGBUS.

-- 
Ticket URL: <http://pulseaudio.org/ticket/806#comment:4>
PulseAudio <http://pulseaudio.org/>
The PulseAudio Sound Server