On Mon, Apr 28, 2014 at 05:25:13PM +0200, Nikos Mavrogiannopoulos wrote:
On Mon, Apr 28, 2014 at 4:49 PM, Martin Kletzander <[email protected]> wrote:On a second read, I don't quite understand what is the issue you're having there. Is it that you do a fork-then-exec, and you see the urandom descriptor open? If you simply do a fork that is expected as the child inherits all the open descriptors.It happens with usual fork-then-exec on some binaries. I'm saying some because I was not able to identify which ones as it doesn't happen for every one. I saw this error when running libvirt test suite (make check) where we have one test checking that we leak no file descriptors into our executed code (apart from other things). However, even if I run that command we are using [1] from shell, it still has these two FDs open. The program just creates a log file with all its file descriptors, environment data, etc. If there's anything I can do to help find the bug, let me know.I could not reproduce it with a program that calls gnutls_global_init() and then forks and execs. Is there a way to reproduce it with libvirt tools?
The program I was using does not do anything with gnutls_global_init(). What I used when bisecting was: tests/commandhelper </dev/null &>/dev/null grep '^FD:' tests/commandhelper.log When everything is ok, you'll see only: FD:0 FD:1 FD:2 However with gnutls with that mentioned commit, I see: FD:0 FD:1 FD:2 FD:3 FD:4 *However*, for this you need to configure libvirt with tests, build them (or at least the commandhelper), etc. I'll try to come up with a simplified source code asap. Martin
signature.asc
Description: Digital signature
_______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
