[gnutls-help] Issues with both gnutls 3.3.0 and 3.3.1
mkletzan at redhat.com
Mon Apr 28 17:36:27 CEST 2014
On Mon, Apr 28, 2014 at 05:25:13PM +0200, Nikos Mavrogiannopoulos wrote:
>On Mon, Apr 28, 2014 at 4:49 PM, Martin Kletzander <mkletzan at redhat.com> 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
>>> open? If you simply do a fork that is expected as the child inherits all
>>> 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  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:
However with gnutls with that mentioned commit, I see:
*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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: Digital signature
More information about the Gnutls-help