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
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
