curl / Mailing Lists / curl-library / Single Mail


Re: open ssl vs gnutls used along with libcurl

From: Daniel Stenberg via curl-library <>
Date: Fri, 5 Oct 2018 11:27:15 +0200 (CEST)

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

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

> 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/
> ==70015== by 0x1014B428: libssh2_init (in /usr/lib64/

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/
> ==70015== by 0x111353A8: ??? (in /usr/lib64/
> ==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...

Received on 2018-10-05