(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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/176902 Title: kpdf locks sound output -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
