415808 - firefox passes open sound file handles to sub processes

Status: VERIFIED DUPLICATE of bug 147659

(Firefox :: Shell Integration, defect)

Description

[Tobias Koenig]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/20071128 Iceweasel/2.0.0.11 (Debian-2.0.0.11-1)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/20071128 Iceweasel/2.0.0.11 (Debian-2.0.0.11-1)

Hej,

firefox doesn't close the file handle for /dev/snd/pcmXXX before it starts a child
process after the fork. That results in the bug as bescribed in http://bugs.kde.org/show_bug.cgi?id=148470, where the sub process disturbs the
parent process, even the child process makes no use of the sound file handle. 

Reproducible: Always

Steps to Reproduce:
1. Setup firefox to use kpdf/okular/acroread for opening PDF files
2. Open a PDF from within firefox
3. Call 'fuser -v /dev/snd/*', you'll see neither firefox nor the PDF viewer uses the  sound device
4. Close the PDF viewer
5. Go to youtube.com and play a flash video with sound
6. While playing, open a second tab and open the PDF document again
7. Call 'fuser -v /dev/snd/*', you'll see both, firefox _and_ the PDF viewer use the sound device
Actual Results:  
firefox leaves the file handles to the child processes.

Expected Results:  
firefox shouldn't leave the file handles to the child processes.

Comment 1

[Elmar Ludwig]

Might be a duplicate of bug 147659, but I'm not sure this covers the case of files opened by plugins (not Firefox itself).

Comment 3

[Tobias Koenig]

Ahh indeed... so any chance to get it fixed? This is not about 'what ugly things can a child process do with open file handles' it is about: 'How to prevent that both processes share a common file handle to a unique resource and so dead lock each other!'
The only clean solution I see is to close all file descriptors between the fork and the exit.

Comment 4

[Elmar Ludwig]

(In reply to comment #3)
> Ahh indeed... so any chance to get it fixed?

Eventually? Yes. Soon? Not likely if you ask me. The problem seems to be that there is no portable way to find all open file descriptors.