#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 _______________________________________________ pulseaudio-tickets mailing list pulseaudio-tickets@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-tickets