Hi , Libcurl version: -sh-4.2$ curl --version curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.43.0 NSS/3.19.1 Basic ECC zlib/1.2.7 libidn/1.28 libssh2/1.4.3
Also in point 2: program is still using gnutls but backtrace shows openssl. I didnot understand why. On Fri, Oct 5, 2018 at 2:57 PM Daniel Stenberg <dan...@haxx.se> wrote: > On Fri, 5 Oct 2018, surya chandrika via curl-library wrote: > > > We have a usecase within program which uses gnu encrypt decrypt function, > > and it reports leaks. > > > > So i was searching a bit about gnu and found this link, where it states > gnu > > used along curl can also leak > > > > https://github.com/curl/curl/issues/1086 > > That's a one way of reading that issue but I would disagree with it. > > I would summarize that issue like this: some people say there's a leak > somewhere when curl uses GnuTLS - but I failed (repeatedly) to reproduce > and > nobody could provide a reproducible test case either. The issue was rather > pointing to a potentially large memory consumption in GnuTLS and no memory > leak. > > > Is there any known issues like curl with gnu has leaks? > > Not to my knowledge. > > > Will switching to openssl solve this problem as stated in this link? > > There is and was no leak in that issue but you can certainly switch and > build > curl with openssl if you like. > > > ==70015== by 0xDD92B4D: OPENSSL_add_all_algorithms_noconf (in > > /usr/lib64/libcrypto.so.1.0.2k) > > ==70015== by 0x1014B428: libssh2_init (in /usr/lib64/libssh2.so.1.0.1) > > That looks like it might be a leak, yes. I would primarily suspect/point > at > libssh2 unless you run a recent version (based on that trace). > > I'm not aware of any known memory leaks in curl with openssl either, using > recent 3rd party components. > > We run tests on our code non-stop and for all commits that also run all > tests > with valgrind and asan and more. (But sure, bugs still happen to slip in!) > > > 3. I have 182 hits for the below backtrace in my valgrind log , although > its > > invoked only once and global cleanup in invoked at the end of program. > This > > program is a long running program and we dont expect to stop or restart > in > > between. > > > ==70015== by 0x11135142: PR_ErrorInstallTable (in > /usr/lib64/libnspr4.so) > > ==70015== by 0x111353A8: ??? (in /usr/lib64/libnspr4.so) > > ==70015== by 0x7E1C0E4: Curl_nss_init (nss.c:1244) > > Now we're using curl + NSS? Yes this looks like a suspicious leak. Do you > run > a recent NSS version? > > You're also not telling us which libcurl version all this is done with. I > would encourage you to use a recent version there as well, to reduce the > risk > that you're seeing problems we've already fixed... > > -- > > / daniel.haxx.se >
------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html