191618 - java_vm never releases /dev/dsp

Status: VERIFIED DUPLICATE of bug 55283

(Firefox :: General, defect)

Description

[Kevin B]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5

Plugins such as flash or java (well, ok, so flash uses java...) will try to open
/dev/dsp (usually whether or not they actually need it), and then keep it open
(if it used it), even after leaving the page (at least in the java case, maybe
in the flash case as well).  This is unacceptable.  My current workaround is to
keep changing /dev/dsp as from a symlink to my real device and a fake one. 
There should be a way to control whether plugins can open the sound device at
all, and closing the page that contained such a plugin should release the
resouce (instead of forcing an entire browser close).

A corallary to this is the converse.  Some other program, say XMMS, has /dev/dsp
open and a plugin is trying to load that wants to open that device (again, it
may or may not actually use the device, but it seems to try anyway... esp.
flash).  The result is the browser will hang (blocks trying to open the device)
until the other process lets go (unfortunately in the case of XMMS this means
'stop' not 'pause' :P).

Reproducible: Always

Steps to Reproduce:
1. Goto a webpage with java with sound (games.yahoo.com has some good ones!)
2. Leave that page
3. lsof /dev/dsp - note the java_vm processes that are spawned from phoenix-bin
(as noted from ps afx)  are listed.

Actual Results:  
I was unable to play sound again until I closed the entire browser.

Expected Results:  
Released the audio device.

My guess is that the java_vm process is left running to speed future loadings of
java applets (this is a good idea, in principle, though in linux this is
partially nullified by it's great file buffer cache), and that since it's the
java_vm that has the device open, forcing it to close it could be difficult
(unless the applet was well written and closes it when it exits, if it is even
asked to (is that the issue?)).
The second case where another app already has the dsp device open and the
browser hangs might be harder to fix, since Phoenix isn't in control at that
point.  I'm not sure what the interaction is that causes the UI to block, though.
Note that I'm pretty sure this all applies equally well to Mozilla proper.

Comment 1

[Sébastien Delahaye]

*** This bug has been marked as a duplicate of 55283 ***

Comment 2

[noririty]

v.