[gnutls-help] Issues with both gnutls 3.3.0 and 3.3.1
Martin Kletzander
mkletzan at redhat.com
Mon Apr 28 16:49:01 CEST 2014
On Mon, Apr 28, 2014 at 03:53:41PM +0200, Nikos Mavrogiannopoulos wrote:
>On Tue, Apr 22, 2014 at 4:01 PM, Martin Kletzander <mkletzan at redhat.com> wrote:
>> Hello,
>> I recently upgraded to gnutls-3.3.0 (from 3.2.13) and found out that
>> there are 2 FDs leaked (read-only, pointing to /dev/urandom) into some
>> processes. Looking at the code it looks like there should be
>> FD_CLOEXEC set, but it leaks through anyway. The backtrace when
>> opening those files is:
>
>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.
Martin
[1] http://libvirt.org/git/?p=libvirt.git;a=blob;f=tests/commandhelper.c;hb=HEAD
-------------- 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/11973258/attachment.sig>
More information about the Gnutls-help
mailing list