Closed Bug 368003 Opened 18 years ago Closed 18 years ago

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

Categories

(Core Graveyard :: File Handling, defect)

Product:
Core Graveyard
Component:
File Handling
Platform:
All
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 147659

People

(Reporter: jwbaker, Unassigned)

Details

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.
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.
Over to core.
Assignee: wtchang → file-handling
Component: NSPR → File Handling
Product: NSPR → Core
QA Contact: nspr → ian
Version: other → Trunk
Summary: ForkAndExec leaves the child process with all of Mozilla's file descriptors → Spawning helper leaves child with all of Mozilla's file descriptors
Dupe of Bug 147659.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.