Comment 90 for bug 102408

(In reply to comment #67)
> So this is the culprit?
> http://mxr.mozilla.org/mozilla-central/source/nsprpub/pr/src/md/unix/
> uxproces.c#263
>
> How exactly do you trigger this? I thought download code used GIO or
> GnomeVFS now to spawn processes.
>
> Is there any valid case for wanting to keep the file descriptors open after
> a fork? I was thinking that, in that function ForkAndExec(), if attr is null
> then I close the fds. karl, thoughts?

My 2 cents:
- The problem is not keeping the file descriptors open after a fork, but after an exec.
- There are a lot of valid reasons to keep file descriptors open after a fork
- There are a few valid reasons to keep file descriptors open after an exec, but I don't think any of these reasons are in the scope of a browser
- Modifying ForkAndExec() behaviour in nspr means a change in behaviour in all applications using NSPR, which may or may not expect file descriptors not to be closed.
- As you pointed out, nowadays GIO and GnomeVFS is used (except for mailcap entries), but I don't think they close file descriptors either.