regarding memory cleanup at end of each DTLS session

Previous Topic Next Topic
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view

regarding memory cleanup at end of each DTLS session


Hi Guys,

  I have a server implementation of DTLS Server using OPENSSL.

  At the end of each DTLS Session however I see that memory usage of process keeps on increasing.

  However on running Valgrind with the process no significant leak is observed.


  So, wanted to know that whether the function calls being done by me on getting DTLS Alerts are proper or not.


  Version being used is OpenSSL 1.0.1e-fips 11 Feb 2013


  On getting DTLS Alert following function calls are being done.



      SSL_free (ssl);



  Where ssl is the SSL* which was created when server got Client Hello for the handshake.


Please advise if I am required to do anymore cleanup on getting DTLS Alert.


  Your advise is highly appreciated.





openssl-users mailing list
To unsubscribe:
Reply | Threaded
Open this post in threaded view

Re: regarding memory cleanup at end of each DTLS session

I did try dumping the memory state after freeing the ssl session at the end of each call using  

Keep getting on the console alternately
74372 bytes leaked in 32 chunks
[18:27:48]  2830 file=pqueue.c, line=95, thread=139766236079872, number=16, address=7F1D6CA32060
[18:27:48]  3013 file=asn1_lib.c, line=425, thread=139766236079872, number=24, address=7F1D6CA505B0
[18:27:22]   406 file=bn_lib.c, line=317, thread=139766236079872, number=256, address=7F1D6CA3CC10
[18:27:48]  2829 file=pqueue.c, line=95, thread=139766236079872, number=16, address=7F1D6CA31FD0
[18:27:48]  3028 file=buffer.c, line=121, thread=139766236079872, number=140, address=7F1D6CA51520
[18:27:48]  3008 file=a_object.c, line=335, thread=139766236079872, number=3, address=7F1D6CA504C0
[18:27:48]  2828 file=pqueue.c, line=95, thread=139766236079872, number=16, address=7F1D6CA31F40
[18:27:48]  3023 file=asn1_lib.c, line=386, thread=139766236079872, number=13, address=7F1D6CA51490
<and other errors>

112191 bytes leaked in 221 chunks
[18:27:22]  1009 file=lhash.c, line=193, thread=139766236079872, number=24, address=7F1D6CA311E0
[18:27:22]    36 file=lhash.c, line=193, thread=139766236079872, number=24, address=7F1D6CA329B0
[18:27:22]   404 file=bn_lib.c, line=317, thread=139766236079872, number=264, address=7F1D6CA3B480
[18:27:22]   400 file=bn_mont.c, line=325, thread=139766236079872, number=104, address=7F1D6CA3BC80
[18:27:22]   401 file=bn_lib.c, line=317, thread=139766236079872, number=128, address=7F1D6CA3AE20
[18:27:22]  1012 file=s3_both.c, line=708, thread=139766236079872, number=17744, address=7F1D6CA42580
[18:27:22]  1008 file=err.c, line=1019, thread=139766236079872, number=600, address=7F1D6CA21C00
[18:27:22]   329 file=bn_lib.c, line=317, thread=139766236079872, number=256, address=7F1D6CA39FF0
[18:27:22]   363 file=bn_lib.c, line=317, thread=139766236079872, number=256, address=7F1D6CA3B160

Is this data conclusive to arrive at a position ??