Memory leaks are observed for libgnutls in multi-thread mode

[tangtong]

Hi,
I have checked the source codes of gnutls, in _gnutls_handshake_hash_init(), which will be called by gnutls_hand_shake, both 
"session->internals.handshake_mac_handle_md5" and "session->internals.handshake_mac_handle_sha" will be initalized by _gnutls_hash_init(), What confuse me is why only _gnutls_hash_init() for MD5 will trigger memory leak, seems under some situation, only sha related resource of a session allocated by _gnutls_hash_init() is released. 

Would anybody give me some advice on this dilema?

Regards
Tony 


From: tang__tong at hotmail.com
To: help-gnutls at gnu.org
Date: Mon, 12 Oct 2009 06:29:09 +0000
Subject: RE: Memory leaks are observed for libgnutls in multi-thread mode








Some more info for issue investigation:
1)I define my own push/pull function for transport;
   gnutls_transport_set_pull_function(session,pullFunc);
   gnutls_transport_set_push_function(session,pushFunc);

2)To support server name extension, I define the certificate call back func for credential:
    gnutls_certificate_server_set_retrieve_function(_x509Cred,certRequestCallBack);
    In certRequestCallBack():
     st->deinit_all = 0;//I think all cert/key information are shared by all session, so should not be released

According to my understanding, all memory allocated in handshake for a session will be released in gnutls_deinit(session). right?

Regards
Tony

From: tang__tong at hotmail.com
To: help-gnutls at gnu.org
Date: Mon, 12 Oct 2009 05:56:34 +0000
Subject: Memory leaks are observed for libgnutls in multi-thread mode








I have redone my test and go through the memory leak points, I get the following info:
> ::findleaks
CACHE     LEAKED   BUFCTL CALLER
00204e08       1 004ab7e8 libclntsh.so.10.1`sigpnm+0x80
0020b188    7816 007f53b0 libgcrypt.so.11`do_malloc+0x54
0020ae08     106 0130e960 libgcrypt.so.11`do_malloc+0x54
0020dc08       1 00c0cd98 libgcrypt.so.11`do_malloc+0x54
0020dc08      63 008a5e78 libgcrypt.so.11`do_malloc+0x54
0020ae08    8153 0043f518 libgcrypt.so.11`do_malloc+0x54
0020b188     422 01046168 libgcrypt.so.11`do_malloc+0x54
0020dc08    8330 00b3d860 libgcrypt.so.11`do_malloc+0x54
0020dc08    8230 01206438 libgcrypt.so.11`do_malloc+0x54
----------------------------------------------------------------------
   Total   33122 buffers, 21130336 bytes
   
> 007f53b0$<bufctl_audit
0x7f53b0:       next            addr            slab
                0               7f3700          21aa50          
0x7f53bc:       cache           timestamp       thread
                20b188          738886035200566511              
0x7f53cc:       lastlog         contents        stackdepth
                1d8000          0               15              
                libumem.so.1`umem_cache_alloc+0x208
                libumem.so.1`umem_alloc+0x44
                libumem.so.1`malloc+0x2c
                libgcrypt.so.11`do_malloc+0x54
                libgcrypt.so.11`_gcry_malloc+0x10
                libgcrypt.so.11`md_enable+0xfc
                libgcrypt.so.11`md_open+0xfc
                libgcrypt.so.11`_gcry_md_open+0x4c
                libgnutls.so.26`wrap_gcry_hash_init+0x60
                libgnutls.so.26`_gnutls_hash_init+0x78
                libgnutls.so.26`gnutls_handshake+0xe8
                libUE.so`_ZN12SSLSETDriver9onReceiveEv+0x268
                libUE.so`_ZN12InTaskRunner3runEv+0x118
                libclassutil.so`_ZN7MThread7routineEv+0x28
                libclassutil.so`_ZN7MThread10thrRoutineEPv+0x1c

All other leaks points also show the same clues: memory leaks happen during the gnutls_handshake.

For the report of MDB, total 21130336 bytes memory leaks are observed. I have launched 167201 session in 3344 seconds. 

Anybody can give me some helps? If I am not using gnutls in the proper way???

Regards
Tony

From: tang__tong at hotmail.com
To: help-gnutls at gnu.org
Date: Sat, 10 Oct 2009 08:21:05 +0000
Subject: Memory leaks are observed for libgcrypt.so.11 in multi-thread mode








Hi,
My program is a multi-thread server(pthread) working in Solaris enviorment, For thread-safe consideration, according to the guide, I have defined the following macro and call the specific function during iniatlization:
GCRY_THREAD_OPTION_PTHREAD_IMPL;
 gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread);

Scenario1:
Launch Tls session one after another to guarantee there is no concurrency existing between tls session, there is no memory leak reported by MDB;


Scenario2:
Launch TLS session concurrently, e.g., 50 TPS,  memory leaks are reported by MDB

> ::findleaks
CACHE     LEAKED   BUFCTL CALLER
00204a88      17 0053b860 libUE.so`_ZN12PacketHelper12createPacketEi+0x34
0020dc08      27 00aea708 libgcrypt.so.11`do_malloc+0x54
0020b188      88 012f0b40 libgcrypt.so.11`do_malloc+0x54
0020dc08     100 013aa000 libgcrypt.so.11`do_malloc+0x54
0020ae08      64 00461e00 libgcrypt.so.11`do_malloc+0x54
0020b188      39 0073a780 libgcrypt.so.11`do_malloc+0x54
0020ae08      65 016cf248 libgcrypt.so.11`do_malloc+0x54
0020dc08     129 00aea7f8 libgcrypt.so.11`do_malloc+0x54
----------------------------------------------------------------------
   Total     529 buffers, 325752 bytes

I have disabled the session reusage and deinit tls sessions structure with gnutls_deinit().

Anybody can give me some tips on this issue?

Regards
Tony










 		 	   		  
使用新一代 Windows Live Messenger 轻松交流和共享！ 立刻下载！ 		 	   		  
使用新一代 Windows Live Messenger 轻松交流和共享！ 立刻下载！ 		 	   		  
使用新一代 Windows Live Messenger 轻松交流和共享！ 立刻下载！ 		 	   		  
_________________________________________________________________
MSN十周年庆典，查看MSN注册时间，赢取神秘大奖
http://10.msn.com.cn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20091013/8df22aad/attachment.htm>