[Help-gnutls] gnutls_dh_params_generate2() leaks file descriptor to /dev/urandom?

[Christian Parpart]

Hi all,

I'm valgrinding my application since a few days, and also ran into 
a file descriptor leak within gnutls_dh_params_generate2();

The following fragment is the backtrace generated by valgrind 
at the time of where the file descriptor has been allocated in:

==3868== Open file descriptor 3: /dev/urandom
==3868==    at 0x1579ADB82: __open_nocancel (in /lib/libpthread-2.3.5.so)
==3868==    by 0x157F01DC6: (within /usr/lib/libgcrypt.so.11.2.0)
==3868==    by 0x157EE728A: (within /usr/lib/libgcrypt.so.11.2.0)
==3868==    by 0x157EE78B7: (within /usr/lib/libgcrypt.so.11.2.0)
==3868==    by 0x157EE82D5: (within /usr/lib/libgcrypt.so.11.2.0)
==3868==    by 0x157F08BAB: gcry_mpi_randomize 
(in /usr/lib/libgcrypt.so.11.2.0)
==3868==    by 0x157EE54A3: (within /usr/lib/libgcrypt.so.11.2.0)
==3868==    by 0x157EE5A53: (within /usr/lib/libgcrypt.so.11.2.0)
==3868==    by 0x157EE6640: gcry_prime_generate 
(in /usr/lib/libgcrypt.so.11.2.0)
==3868==    by 0x156F332E8: _gnutls_dh_generate_prime 
(in /usr/lib/libgnutls.so.12.3.1)
==3868==    by 0x156F33611: gnutls_dh_params_generate2 
(in /usr/lib/libgnutls.so.12.3.1)
==3868==    by 0x15690DCE1: TCredentials::TCredentials() (secnet.cpp:107)
==3868==    by 0x156910941: TSecureNetworkServer::TPrivate::TPrivate() 
(secnet.cpp:175)
==3868==    by 0x15690E940: TSecureNetworkServer::TSecureNetworkServer() 
(secnet.cpp:274)
==3868==    by 0x1554A5CE9: yacs::TServer::TServer(int, 
System::TStringBase<char> const&, System::TStringBase<char> const&, 
System::TStringBase<char> const&, System::TStringBase<char> const&, 
System::TStringBase<char> const&, System::TStringBase<char> const&, 
System::Diagnostics::ILogger*, System::TStringBase<char> const&, unsigned, 
System::TStringBase<char> const&, System::TStringBase<char> const&) 
(TServer.cpp:90)
==3868==    by 0x41DEAF: spawnServer() (yacsd.cpp:281)
==3868==    by 0x41FF6C: main (yacsd.cpp:388)

Well, is there anything I need to call as cleanup routine? Or why is it 
holding a link up to /dev/urandom all the runtime over and w/o closing at 
shutdown?

Regards,
Christian Parpart.

-- 
 15:57:12 up 147 days,  5:04,  1 user,  load average: 1.89, 3.81, 4.23
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: </pipermail/attachments/20050817/1aff46ec/attachment.pgp>