Spawning helper leaves child with all of Mozilla's file descriptors

RESOLVED DUPLICATE of bug 147659

Status

Core Graveyard
File Handling
RESOLVED DUPLICATE of bug 147659
12 years ago
2 years ago

People

(Reporter: Jeffrey Baker, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
ForkAndExec() at nsprpub/pr/src/md/unix/uxproces.c#167 forks and execs a new unix process.  Frequently this is a helper app like Adobe Reader.

Anyway, after the fork() and before the execv() the child does not close its file descriptors.  So the helper app winds up inheriting hundreds of sockets, pipes, and files (bookmarks, chrome, cache, etc).  If the user quits the browser but leaves the helper open, the browser will refuse to start because the child still has the profile locked.

NSPR should close all of its file descriptors starting with 3 and up to RLIMIT_NOFILE.  Or, ForkAndExec() should have a parameter controlling file closure.
(Reporter)

Comment 1

12 years ago
Now that I've looked into it, this doesn't seem like an NSPR problem.  PR_SetFDInheritable works as advertised.  Unfortunately nothing in SeaMonkey ever calls that function.  I need to find another product to which to assign this bug.
(Reporter)

Comment 2

12 years ago
Over to core.
Assignee: wtchang → file-handling
Component: NSPR → File Handling
Product: NSPR → Core
QA Contact: nspr → ian
Version: other → Trunk
(Reporter)

Updated

12 years ago
Summary: ForkAndExec leaves the child process with all of Mozilla's file descriptors → Spawning helper leaves child with all of Mozilla's file descriptors
(Reporter)

Comment 3

12 years ago
Dupe of Bug 147659.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 147659
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.