Hi Brad, Your suggestions is worked very well. Particularly I got very decreased memory leaks when I called global clean up functions at last.
I also solved 66000byte memory leak as it was happening only because some silly bad programming in my modified libcsoap's hssl_client_ssl function. (btw. I don't know who had modified my libcsoap code.) Now at last, there is only 48 bytes leak of (in 0.9.8k and 1.0.0 beta1 its 36 bytes) of SSL_library_init(), is of not a big issue but I will have look into openssl to just as minimize as I can. (Because restarting the application many times will slowly eat up the memory.. and will require to restart the system) Also One remaining thing is regarding invalid read/invalid write messages, Does compiling OpenSSL with -DPURIFY will cause any performance/stability issue? OR is it necessary for good working of the application.? OR is it just for the faint of the heart? Thanks, msp Brad House wrote: > > Commenting below. > >> For better clarification, I have attached the trace of Valgrind on the >> Pastebin: >> http://pastebin.com/f1e222abd >> Here is the last lines.... >> >> 1. ==3290== LEAK SUMMARY: >> 2. ==3290== definitely lost: 268 bytes in 1 blocks. >> 3. ==3290== indirectly lost: 66,807 bytes in 23 blocks. >> *********************!!!! >> 4. ==3290== possibly lost: 0 bytes in 0 blocks. >> 5. ==3290== still reachable: 2,536 bytes in 118 blocks. >> 6. ==3290== suppressed: 0 bytes in 0 blocks. > > ok... > >> Above is the leak for per HTTPS request/response, >> On each succeeding request/response, leaks on line 2, 3 and 4 get >> incremented, only 4th leak -- still rechable -- remain as it is. >> >> I checked libcsoap library thoroughly, at the end it call the below two >> function for clean up any used memory, they are in sequence: >> *SSL_shutdown(sock->ssl) >> **SSL_free(sock->ssl) > > Without looking at the code, if you are losing more bytes for > every connection, it's possible there is a CTX which was initialized > and floating out there but never free'd. It looks like from your > pastebin, > that hssl_client_ssl (nanohttp-ssl.c:412) is calling SSL_CTX_new() but > is most likely never SSL_CTX_free()'ing the data. > > Also, you've got to realize that when SSL_library_init() is called, some > memory is allocated globally that if you expect a clean valgrind trace > will need to be freed. As far as I am aware, there is no general > SSL_library_destroy() type function ... in my own code, I use something > like this to free that global memory when my application shuts down > so I can get a clean valgrind trace: > ERR_remove_state(0); > ENGINE_cleanup(); > CONF_modules_unload(1); > ERR_free_strings(); > EVP_cleanup(); > CRYPTO_cleanup_all_ex_data(); > I think that usually covers most if not all of the memory lost from > initialization. > >> *Even though the leak is present and detected in valgrind.* >> *Is there any solution or work around for solving this leak. >> On searching the net i found to configure/compile openssl with -DPURIFY >> option. but it didn't worked. > > -DPURIFY just helps resolve some invalid read/invalid write messages, > doesn't have anything to do with memory leaks. > >> My system is Fedora 8, >> And OpenSSL Library version is 0.9.8b > > Wow, you shouldn't be using 0.9.8b ... > >> I also tried the latest openssl 1.0.0 Beta1, the same memory leaks comes >> there. > > I haven't yet tried that release, but I wouldn't expect any leaks there... > especially the _same_ ones as such an old release as 0.9.8b ;) > > -Brad > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [email protected] > Automated List Manager [email protected] > > -- View this message in context: http://www.nabble.com/Memory-leak-while-using-OpenSSL-library-tp22974346p22998182.html Sent from the OpenSSL - Dev mailing list archive at Nabble.com. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
