(In reply to comment #51)
> This bug hits me *every single day*. I play mp3's (usually internet radio
> using rhythmbox or songbird) and use firefox extensively, reading lots of pdf
> documents with xpdf. After some time, xpdf will block the sound device and I
> have to go track down which pid is blocking it and kill all the documents I
> have open (usually I have several). The choice by ubuntu to use pulseaudio
> seems to make the situation worse. I usually find it's the first thing I have
> to kill, then it's xpdf sessions, or firefox itself.
I am pretty sure that the PA libraries set O_CLOEXEC on all its fds. What makes you think PA is at fault here?
(In reply to comment #51)
> This bug hits me *every single day*. I play mp3's (usually internet radio
> using rhythmbox or songbird) and use firefox extensively, reading lots of pdf
> documents with xpdf. After some time, xpdf will block the sound device and I
> have to go track down which pid is blocking it and kill all the documents I
> have open (usually I have several). The choice by ubuntu to use pulseaudio
> seems to make the situation worse. I usually find it's the first thing I have
> to kill, then it's xpdf sessions, or firefox itself.
I am pretty sure that the PA libraries set O_CLOEXEC on all its fds. What makes you think PA is at fault here?
That said, regardless whether PA is misbehaving here or not, firefox definitely needs to close all open fds after fork()ing and before exec()ing an application. On linux this is best done by iterating through /proc/self/fd. Something like this: git.0pointer. de/?p=pulseaudi o.git;a= blob;f= src/pulsecore/ core-util. c;h=b64c51e18fb 71d2a111b0a0236 bc81bc5d849950; hb=HEAD# l2230
http://
That code is fast on Linux and still compatible with non-Linux Unixes, so should be a safe choice.