[gnutls-help] Issues with both gnutls 3.3.0 and 3.3.1

[Martin Kletzander]

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
>>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: </pipermail/attachments/20140428/84f873d8/attachment-0001.sig>