Comment 28 for bug 226342

@weirdbro

<i>
The reason that this freezes up all applications is because when pulseaudio is locked up, it locks up gconf, which many other applications depend upon. I've had to prevent pulseaudio from starting on my machine by removing it from the session preferences. Is there a reason that pulseaudio gets locked up by other applications. Also, has anyone else noticed that Pidgin goes wild and leaks memory at a horrendous rate once Pulseaudio is killed? Happens to me every time.
</i>

All right - it's well into august 2008 now. I'm seeing exactly the same behavior on Hardy:

a) an application locks up the audio device (in my case, 'mpc pause')
b) no sound. Pulseaudio starts complaining.
c) after a while, large chunks of the desktop stop working - new applications can't be started, most of the panel disappears

So if you dare to kill pulsaudio (that's a kill -9, thank you, pulseaudio doesn't even respond to a gentle kill) while pidgin is running, pidgin starts leaking memory like there's no tomorrow - pretty soon (a few minutes on this machine with 2GB of ram) it eats all your ram + swap and you're dead in the water.

If you kill pidgin first, and then kill pulseaudio, suddenly sound works again.

It seems to me there are multiple bugs here:

a) pidgin should not leak memory like that. Ever.

b) pulseaudio needs to be smarter about dealing with sound devices that are locked up. If other applications are doing something they should not be (i.e. locking up the sound device) pulseaudio should deal with this gracefully. Not responding to a gentle kill? Locking gconf? Those are bugs, I'm sorry. Nasty bugs. Marking bugs like upstream #313 as invalid is ... not productive. Why is pulseaudio locking gconf?

c) mpc and friends should stop locking up audio devices. Duh.