Closed
Bug 204151
Opened 21 years ago
Closed 17 years ago
A process created by PR_CreateProcess with an inherited fd can't pass any inheritable fd to a child process created by PR_CreateProcess.
Categories
(NSPR :: NSPR, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
4.7
People
(Reporter: wtc, Assigned: wtc)
Details
Attachments
(1 file, 1 obsolete file)
4.20 KB,
patch
|
sfraser_bugs
:
review+
|
Details | Diff | Splinter Review |
If a process was itself created by PR_CreateProcess with an inherited fd, it won't be able to pass any inheritable fd's to a child process created by PR_CreateProcess. NSPR passes the values of inheritable fd's in a magic environment variable in the child process's environment. If a process was itself created by PR_CreateProcess, it will have that magic environment variable in its environment. If this process calls PR_CreateProcess with an inheritable fd, it will append the magic environment variable to the current environment, without checking if the magic environment variable already exists. So the child's environment array ends up with two entries of that magic environment variable, with the wrong one appearing before the right one. When the child process gets its inherited fd, it gets the wrong value.
Assignee | ||
Comment 1•21 years ago
|
||
Search for existing NSPR_INHERIT_FDS environment variable in the environment. If it exists, replace it with the new value rather than appending the new value to the environment.
Assignee | ||
Updated•21 years ago
|
Attachment #124021 -
Flags: review?(sfraser)
Assignee | ||
Updated•21 years ago
|
Attachment #124021 -
Flags: review?(sfraser)
Assignee | ||
Comment 2•21 years ago
|
||
The previous patch has a bug in the Windows code. The second argument to qsort() may be incorrect.
Attachment #124021 -
Attachment is obsolete: true
Assignee | ||
Updated•21 years ago
|
Attachment #124044 -
Flags: review?(sfraser)
Comment 3•19 years ago
|
||
Do we still need this?
Assignee | ||
Comment 4•19 years ago
|
||
Yes, we should still fix this bug even though the affected customer has implemented a workaround.
Updated•19 years ago
|
Attachment #124044 -
Flags: review?(sfraser_bugs) → review+
Updated•18 years ago
|
QA Contact: wtchang → nspr
Comment 5•17 years ago
|
||
is this ready for check in?
Assignee | ||
Comment 6•17 years ago
|
||
I checked in the patch on the NSPR trunk for NSPR 4.7. Checking in beos/bproc.c; /cvsroot/mozilla/nsprpub/pr/src/md/beos/bproc.c,v <-- bproc.c new revision: 3.7; previous revision: 3.6 done Checking in unix/uxproces.c; /cvsroot/mozilla/nsprpub/pr/src/md/unix/uxproces.c,v <-- uxproces.c new revision: 3.21; previous revision: 3.20 done Checking in windows/ntmisc.c; /cvsroot/mozilla/nsprpub/pr/src/md/windows/ntmisc.c,v <-- ntmisc.c new revision: 3.23; previous revision: 3.22 done
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Target Milestone: --- → 4.7
You need to log in
before you can comment on or make changes to this bug.
Description
•