This bug affects all Unix platforms. When NSPR creates a new PRFileDesc, it asserts that the close-on-exec (FD_CLOEXEC) flag of the Unix file descriptor is cleared. (This assertion is in function pt_SetMethods in ptio.c.) While this is true for Unix file descriptors opened by NSPR (the FD_CLOEXEC flag is cleared by default), we cannot make this assumption on Unix file descriptors that are not opened by NSPR, such as stdin, stdout, stderr, and the Unix file descriptors being imported into NSPR, because their close-on-exec flag may have been set by code outside NSPR.
Some comments on the patch (attachment id=12054). 1. I define a new three-state boolean type _PRTriStateBool, which has an "unknown" state _PR_TRI_UNKNOWN (-1). The type of fd->secret->inheritable is changed from PRBool to _PRTriStateBool to allow the 'inheritable' attribute of a fd to be unknown. 2. In classic NSPR, _PR_MD_INIT_FILEDESC() (called by PR_AllocFileDesc()) is now a no-op on Unix. It used to set fd->secret->inheritable to PR_TRUE. 3. I added two new MD functions. In classic NSPR: void _PR_MD_INIT_FD_INHERITABLE(PRFileDesc *fd); Use this function after _PR_Getfd() or PR_AllocFileDesc() (which calls _PR_Getfd()). In both classic and pthreads NSPR: void _PR_MD_QUERY_FD_INHERITABLE(PRFileDesc *fd, PRBool imported); 4. In the pthreads version, pt_SetMethods() has a new 'imported' argument. 5. 'imported' is true for the following functions: PR_ImportFile, PR_ImportPipe, PR_ImportTCPSocket, PR_ImportUDPSocket, and the creation of the file descriptors _pr_stdin, _prstdout, _pr_stderr. 'imported' is false for PR_Open, PR_OpenFile, PR_CreatePipe, PR_Socket, and PR_NewTCPSocketPair. I don't know whether 'imported' should be true or false for the newly accepted socket returned by PR_Accept or PR_AcceptRead, because I don't know whether the accepted socket has the same inheritability attribute as the listening socket. I decided to do nothing to the code in this area so the current behavior stays unchanged, whether it's correct or not.
I checked in the patch (attachment id=12054) on the main trunk. However, I found that the NT code can be improved. I will post another patch for that.
I checked in the revised patch (attachment id=12060) on the main trunk. Marked the bug fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.