Google-drive-ocamlfuse: Memory leak when continuous usage

[JohNan]

I have run a more or less continuous upload/copy of files for the past 2 days. Since I started the progress the memory consumption of the google-drive-ocamlfuse binary has grown and grown. At the moment it consumes roughly 34GB.

To get the memory freed up I stopped the upload/copy and run the following

$ sync
$ unmount <mountpoint>
$ google-drive-ocamlfuse <mountpoint>

What kind of information can I provide you to help getting this resolved?

google-drive-ocamlfuse, version 0.5.25

The process was restarted at 16.00 on the 9th, hence the drop.

[astrada]

What kind of information can I provide you to help getting this resolved?

Are you using the default configuration? Do you use some kind of non-default command switches (e.g. -m)?

[JohNan]

Thanks for the quick response.

No, I'm not using any special switches. Simply the command that I wrote above. It is a headless server though, so the setup is the only non-default configuration that has been used.

[brancomat]

As a side node:
with the help of @astrada I recently used memleax to diagnose a suspect memory leak and it turned out to be an issue of libcurl compiled against nss (https://bugzilla.redhat.com/show_bug.cgi?id=1057388 and also https://bugzilla.mozilla.org/show_bug.cgi?id=1202413).
I had to recompile libcurl against openssl to avoid it.

[rootministrator]

I think I have also bumped to a memory leak issue.
I have google-drive-ocamlfuse installed on a RPI3 (running osmc, which is basicly Debian / Raspbian).
I would like to use the service to stream large video files (often >10GB) from my google drive on the PI with Kodi.

I currently use these modified settings:
max_memory_cache_size=50485760
memory_buffer_size=15485760
read_ahead_buffers=1

I've been playing around with the numbers above for a while. With default config it was not good at all, however these limits it seems to be OK for most files. At least for a couple of minutes... Then, it is a complete disaster, sometimes even the player crashes.

I started monitoring memory usage, and I noticed that free memory goes from ~440 MB to below 30 MB (in approx 5 minutes, depending on the bitrate)
As for my understanding, "_max_memory_cache_size=50485760_" should set the maximum allocated cache memory to ~50MB, not a single byte more, and that is definetly what happens.

Can you please look up to this, @astrada? Can you suggest some workarounds I can try before a proper fix of the issue?
If you need any further details to investigate this issuse, feel free to ask.
Thx in advance!

[astrada]

Which version are you testing?

[rootministrator]

I have installed it with OPAM about 3 weeks ago.
According to the '_state_' next to the configuration it is: saved_version=0.6.17

I had to manually install a couple of dependencies within opam, because _depext_ was not familiar with my distribution.
(I'm adding this only because it might have something to do with the issuse, however I think every package installation went well, and also, GDO works fine except this leak issue)

[astrada]

You can try the latest beta version (0.6.18) with:

opam pin add google-drive-ocamlfuse https://github.com/astrada/google-drive-ocamlfuse.git#beta

To restore the stable version:

opam pin remove google-drive-ocamlfuse

[rootministrator]

Do I need a special switch for opam to upgrade to beta releases?

I did opam update, and upgrade after pinning, but I got back 0.6.17.

When I do an opam update now, I get:

=-=- Synchronizing development packages -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[google-drive-ocamlfuse] https://github.com/astrada/google-drive-ocamlfuse.git#beta already up-to-date

[astrada]

Opam should report 0.6.17 (because the new version is not in the official repository yet). But if you run google-drive-ocamlfuse -version and get 0.6.18, then you got the new beta version.

[rootministrator]

Thanks!

I'm on 0.6.18 now, and the issue is still persistent. I've started to play with kodi's own cache settings (even fully disabling it), but makes no difference.
I tested sharing movies on my local network, kodi plays fine, with >400 MB of free memory.

However, if I start streaming from google drive, free memory 'vanishes' in 5 minutes. I ran _top_ command, to follow memory usage, the interesting thing is not the GDO process itself takes the memory over (it uses about ~10-20%, depending on cache settings, which is fine, kodi takes also about ~20%, and the rest is just gone, I mean it is not listed by _top_.

That's why I suspect it is a memory leak, but I am up to suggestions, what to test.

[astrada]

You should check if your libcurl is compiled with NSS as TLS provider. It can be the same issue reported here, here, or here.

[jheyneman]

How does one replace libcurl? I compiled curl from source with ./configure --with-ssl and installed it. I'm still getting a steady increase in RAM usage when using Plex until the system runs out of memory or I get the "Transport endpoint is not connected" message if I try to access the mount.

It seems I installed it correctly...

$ curl -V
curl 7.54.0 (x86_64-pc-linux-gnu) libcurl/7.54.0 OpenSSL/1.0.2k zlib/1.2.8

[astrada]

@jheyneman: you should check that your system will use your version of libcurl running

pkg-config --variable=libdir libcurl

and checking that it returns the path of your recompiled version. Then you have to recompile ocurl, gapi-ocaml, and google-drive-ocamlfuse

opam reinstall ocurl gapi-ocaml google-drive-ocamlfuse

[jheyneman]

@astrada I should have mentioned that I installed from your PPA, and I'm on Ubuntu 16.04. The command you suggested returned:

$ pkg-config --variable=libdir libcurl
/usr/local/lib

Definitely pointing to the correct one, shows mod date of yesterday.

edit: I uninstalled and reinstalled with opam. I'll see how that goes for a while.

[JustinGrote]

Seeing similar issue on Ubuntu 16.04LTS. Here's the relevant section from my config (streaming is enabled):

keep_duplicates=false
large_file_read_only=true
large_file_threshold_mb=16
log_directory=/var/log/google-drive-ocamlfuse
lost_and_found=false
low_speed_limit=0
low_speed_time=0
map_format=desktop
map_icon=
max_cache_size_mb=512
max_download_speed=0
max_memory_cache_size=10485760
max_retries=8
max_upload_chunk_size=10995116
max_upload_speed=0
memory_buffer_size=1048576
metadata_cache_time=60
presentation_format=pdf
presentation_icon=
read_ahead_buffers=3

Per above I would expect max cache memory to be 10 meg right (plus some overhead I would expect for the code so ~15-20 meg). Right now it's using ~300 meg

Not sure if my libcurl was complied with TLS as mentioned above, just using the defaults. Here's my curl-v output

# curl -V
curl 7.47.0 (x86_64-pc-linux-gnu) libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP UnixSockets

[ghost]

This problem still exists on version 0.6.19, with default config (streaming enabled, everything else is unchanged).

# curl -V
curl 7.47.0 (x86_64-pc-linux-gnu) libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP UnixSockets

[VarmingDK]

I have the same problem - memory consumption just keeps growing on Ubuntu 16.04
curl 7.47.0 (x86_64-pc-linux-gnu) libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3
google-drive-ocamlfuse, version 0.6.19

[CrystalMediaDesign]

I had the same problem with curl using GnuTLS as its TLS backend on Ubuntu 16.04. I switched to OpenSSL and it seems to be fine now. Here's how I did it;

1- Remove the installed version of curl using;
sudo apt-get purge curl

2- Download the latest version of curl tarball from here;
http://curl.haxx.se/download.html

3- Extract, make and install

You need to make sure there is an OpenSSL dev lib available on your system or SSL will not be enabled. You can either build OpenSSL from source or install libssl-dev with sudo apt-get install libssl-dev.

tar -xvzf curl-*.tar.gz
cd curl-*
./configure --libdir=/usr/lib/x86_64-linux-gnu
make
sudo make install

Optional: If you'd like to specify your compiled version of OpenSSL you can use ./configure --with-ssl=/usr/local/ssl. You can obtain the latest tarballs from https://github.com/openssl/openssl/releases

4- Verify that curl is using OpenSSL
curl -V
output: curl 7.54.0 (x86_64-pc-linux-gnu) libcurl/7.54.0 OpenSSL/1.0.2g zlib/1.2.8

Note: Make sure that curl and libcurl show the same version number i.e 7.54.0 in the above output. If that is not the case, you might need to replace the old libcurl version with the new one, otherwise curl won't work.

see here: https://juniway.blogspot.de/2015/12/curl-48-unknown-option-was-passed-in-to.html

5- Recompile google-drive-ocamlfuse
opam reinstall ocurl gapi-ocaml google-drive-ocamlfuse

You can verify google-drive-ocamlfuse is using the right libcurl using ldd
ldd /path/to/google-drive-ocamlfuse

The output should look something like this.
libcurl.so.4 => /usr/local/lib/libcurl.so.4 (0x00007f01e72e1000)

[VarmingDK]

I've followed the step by step guide above and at step 4 I get this:
curl 7.54.0 (x86_64-pc-linux-gnu) libcurl/7.54.0 OpenSSL/1.0.2g zlib/1.2.8

Which is what we want. I then do the step 5 and fixed the compilation errors but when I ldd I get this:
libcurl-gnutls.so.4 => /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 (0x00007fc54f760000)

Any ideas to what could have gone wrong?

[VarmingDK]

I just tried building OpenSSL as well but I still in step 5 see libcurl-gnutls :(

[CrystalMediaDesign]

What do you see if you try?

which google-drive-ocamlfuse

[VarmingDK]

I see this:
/usr/bin/google-drive-ocamlfuse

and with ldd I see this:
$ ldd /usr/bin/google-drive-ocamlfuse libcurl-gnutls.so.4 => /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 (0x00007f89fd4df000) libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007f89fbbf0000)

Also a lot more lines but those must be the relevant ones.

[CrystalMediaDesign]

I think that is the PPA version. You need to uninstall that and install using opam.

To uninstall try apt remove google-drive-ocamlfuse.

If you have already installed using opam, google-drive-ocamlfuse might not be in your system path. To fix that you can try adding this to ~/.profile.

# OPAM configuration
. $HOME/.opam/opam-init/init.sh > /dev/null 2> /dev/null || true

see https://github.com/astrada/google-drive-ocamlfuse/issues/114

[VarmingDK]

It is the PPA - the guide didn't say otherwise (and I'm new to building). How do I install using opam?

EDIT: Found it in the Wiki

[CrystalMediaDesign]

To install using opam, try the following;

sudo apt-get install opam ocaml make fuse camlp4-extra build-essential pkg-config

opam init
opam install depext
opam depext google-drive-ocamlfuse
opam install ocurl gapi-ocaml google-drive-ocamlfuse

[VarmingDK]

Installed by opam instead but now I get nothing when doing the
which google-drive-ocamlfuse

So I don't know with which directory to try the ldd command..?

[CrystalMediaDesign]

Did you try adding the following to ~/.profile?
It should fix google-drive-ocamlfuse not found.

# OPAM configuration
. $HOME/.opam/opam-init/init.sh > /dev/null 2> /dev/null || true

google-drive-ocamlfuse is probably in ~/.opam/system/bin/

[VarmingDK]

Great - now I got this on ldd:
$ ldd ~/.opam/system/bin/google-drive-ocamlfuse linux-vdso.so.1 => (0x00007ffc6c9fc000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007fcf70d8d000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fcf70b70000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fcf70955000) libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fcf706d5000) libcurl.so.4 => /usr/local/lib/libcurl.so.4 (0x00007fcf7046b000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fcf70262000) libfuse.so.2 => /lib/x86_64-linux-gnu/libfuse.so.2 (0x00007fcf70026000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcf6fd1d000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fcf6fb18000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcf6f74f000) /lib64/ld-linux-x86-64.so.2 (0x00005585caf39000) libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007fcf6f4e6000) libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007fcf6f0a1000)

But I still get google-drive-ocamlfuse not found even after adding to ~/.profile. Should I do something after adding the OPAM configuration (like restarting something or )?

[VarmingDK]

I got it - had to logout of the SSH and login again :) Thanks A LOT for helping! Now I just gotta test.

[CrystalMediaDesign]

Glad to hear that :)

[SteelyNinja]

Ignore now solved.

For info if you update curl to version 7.54 as per guide above, you can then not install via OPAM it fails with "curl: option --compressed: the installed libcurl version doesn't support this" error

Rolled back to old curl - installed then upgraded and works ok.

[SteelyNinja]

Quick update after trying this for a couple of days.

The memory leak appears to be gone which is really good but, this process produces a fixed version based on 0.6.17

I was previously running the beta 0.6.19 which did seem to fix some of the dropping issues that are now back!

Seems I can have the odd drop, or less drops and a memory leak at the moment.

is there any way to fix this memory leak in the 0.6.19 somehow?

[astrada]

With opam you can switch to 0.6.19 with:

opam pin add google-drive-ocamlfuse https://github.com/astrada/google-drive-ocamlfuse.git#beta

To restore 0.6.17:

opam pin remove google-drive-ocamlfuse

Note that opam list will still report version 0.6.17, but google-drive-ocamlfuse -version should show 0.6.19. If not, run opam reinstall google-drive-ocamlfuse.

[SteelyNinja]

Perfect - now trialing 0.6.19 with memory leak fix.

[jant90]

I'm running Manjaro (Arch based distro) and curl and libcurl are up to date and using OpenSSL and I installed google-drive-ocamlfuse 0.6.17 through the AUR and I too see a memory leak.

Right after mounting memory usage of google-drive-ocamlfuse is usually only around 15MB. However when I start streaming a large file memory usage increases to around 130-180MB, and even though that's more than the limit I've configured that is perfectly acceptable for me if that memory would free up as soon as the file has been read (large file stream ends).

So I tried reading 4 files of 1GB from the mountpoint simultaneously and I saw memory usage increasing to over 500MB. And when the files were fully read memory usage stayed at that 500MB. The only way to get memory back down was to unmount and mount again. While still mounted (with memory usage at around 500MB I read 4 different large files simultaneously again, this time the increase in memory wasn't that much, it increased to around 600MB. And in fact I even noticed a few small drops in memory while the files were read (e.g. 550MB, 540MB, 560MB) indicating that the internal memory cleanup is doing something I guess.

After a while (I usually check my system a day later or something) I often find google-drive-ocamlfuse's memory usage at 1100-2100MB.

So is there anything I can try to reduce memory usage by google-drive-ocamlfuse?

I use these custom settings for google-drive-ocamlfuse:

max_memory_cache_size=78643200 # 75MB
memory_buffer_size=7864320 # 7.5MB
read_ahead_buffers=1
stream_large_files=true

Some information about my system:

$ curl -V
curl 7.54.0 (x86_64-pc-linux-gnu) libcurl/7.54.0 OpenSSL/1.1.0f zlib/1.2.11 libpsl/0.17.0 (+libicu/59.1) libssh2/1.8.0 nghttp2/1.22.0
$ ldd /usr/bin/google-drive-ocamlfuse
        [...]
        libcurl.so.4 => /usr/lib/libcurl.so.4 (0x00007fe9c15ec000)
        [...]
        libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x00007fe9c001d000)
$ ldd /usr/lib/libcurl.so.4
        [...]
        libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x00007f0abfdc6000)

[astrada]

So is there anything I can try to reduce memory usage by google-drive-ocamlfuse?

No, sorry, there are lots of buffers I can't control from the application (mainly FUSE buffers and libcurl buffers). If you need a low memory footprint application you should look for another implementation.

[jant90]

A few days ago I updated to 0.6.20 beta (from 0.6.17 stable) and while it may be too early to tell I do believe I see huge improvements in memory usage, awesome! No more than 250MB RAM usage so far. Lets see if it can get through the week without a mount drop or error of some sort, I have a good feeling that it will with all the fixes done in the beta's. Thank you @astrada!

[Anonymousey]

I'm still getting memory leaks with the latest version

[nikitasp]

with version 0.6.24 it became even bigger problem. It consumed 6.8 Gb in 20 hours.

[astrada]

Should be fixed in the latest versions.

[HendrikSchmidt]

Hi, I'm running version 0.7.21 on Ubuntu 18.04 (installed through OPAM) but I still get the occasional failure (once every few days).

[406236.877091] Out of memory: Kill process 13559 (google-drive-oc) score 947 or sacrifice child
[406236.881158] Killed process 13559 (google-drive-oc) total-vm:16522432kB, anon-rss:15283812kB, file-rss:0kB, shmem-rss:0kB
[406237.573846] oom_reaper: reaped process 13559 (google-drive-oc), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

The machine has 16GB and the program exceeded 80% memory usage.

When I run curl -V I get

curl 7.58.0 (x86_64-pc-linux-gnu) libcurl/7.58.0 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3

which looks good, however ldd /home/ubuntu/.opam/default/bin/google-drive-ocamlfuse yields

...
 libcurl-gnutls.so.4 => /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 (0x00007ffbc7aa8000)
...

So I don't think this issue has been fixed yet?

[astrada]

Yes, you should try to install libcurl4-openssl-dev (and remove libcurl4-gnutls-dev), then opam reinstall ocurl gapi-ocaml google-drive-ocamlfuse. But I don't know if some other package depends on the gnutls version.

[HendrikSchmidt]

Now I get libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4 (0x00007fd78b78f000)! Hope that fixed it. Neither libcurl4-openssl-dev nor libcurl4-gnutls-dev where present on the server before (google-drive-ocamlfuse is pretty much the only thing running on a fresh Ubuntu install). Why is google-drive-ocamlfuse still being installed using the gnutls encryption instead of using the same library as curl on the machine? Or is that outside of your control?

Thanks for your quick help!

[astrada]

Or is that outside of your control?

Yes, I depend on ocurl that depends on libcurl4-gnutls-dev via the conf-libcurl package.

[HendrikSchmidt]

After reinstalling and remounting yesterday, I just checked the process this morning, it is again consuming more than 3GB. When I run pmap, i still get a lot of these:

...
00007fbc37ff1000     60K -----   [ anon ]
00007fbc38000000  65528K rw---   [ anon ]
00007fbc3bffe000      8K -----   [ anon ]
00007fbc3c000000  65520K rw---   [ anon ]
00007fbc3fffc000     16K -----   [ anon ]
00007fbc40000000  65508K rw---   [ anon ]
00007fbc43ff9000     28K -----   [ anon ]
00007fbc44000000  65512K rw---   [ anon ]
00007fbc47ffa000     24K -----   [ anon ]
00007fbc48000000  65536K rw---   [ anon ]
00007fbc4c000000  65532K rw---   [ anon ]
00007fbc4ffff000      4K -----   [ anon ]
00007fbc50000000  65532K rw---   [ anon ]
00007fbc53fff000      4K -----   [ anon ]
00007fbc54000000  65524K rw---   [ anon ]
00007fbc57ffd000     12K -----   [ anon ]
00007fbc58000000  65516K rw---   [ anon ]
...

Any idea why this still happens?

[HendrikSchmidt]

This is my output for ldd /home/ubuntu/.opam/default/bin/google-drive-ocamlfuse

linux-vdso.so.1 (0x00007ffdf4f90000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f1726d8c000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1726b6d000)
libfuse.so.2 => /lib/x86_64-linux-gnu/libfuse.so.2 (0x00007f1726931000)
libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4 (0x00007f17266b2000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f17264aa000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f172628d000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f172600c000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1725c6e000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1725a6a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1725679000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1727a4a000)
libnghttp2.so.14 => /usr/lib/x86_64-linux-gnu/libnghttp2.so.14 (0x00007f1725454000)
libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0 (0x00007f1725237000)
librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1 (0x00007f172501b000)
libpsl.so.5 => /usr/lib/x86_64-linux-gnu/libpsl.so.5 (0x00007f1724e0d000)
libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f1724b80000)
libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f17246b5000)
libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f172446a000)
libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f1724218000)
liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f172400a000)
libunistring.so.2 => /usr/lib/x86_64-linux-gnu/libunistring.so.2 (0x00007f1723c8c000)
libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007f1723926000)
libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 (0x00007f17236f2000)
libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x00007f17234bc000)
libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f17231e6000)
libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f1722fb4000)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f1722db0000)
libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f1722ba5000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f172298a000)
libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f172276f000)
libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3 (0x00007f172252e000)
libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f17221ff000)
libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f1721fec000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f1721de8000)
libheimntlm.so.0 => /usr/lib/x86_64-linux-gnu/libheimntlm.so.0 (0x00007f1721bdf000)
libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26 (0x00007f1721952000)
libasn1.so.8 => /usr/lib/x86_64-linux-gnu/libasn1.so.8 (0x00007f17216b0000)
libhcrypto.so.4 => /usr/lib/x86_64-linux-gnu/libhcrypto.so.4 (0x00007f172147a000)
libroken.so.18 => /usr/lib/x86_64-linux-gnu/libroken.so.18 (0x00007f1721264000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f172105c000)
libwind.so.0 => /usr/lib/x86_64-linux-gnu/libwind.so.0 (0x00007f1720e33000)
libheimbase.so.1 => /usr/lib/x86_64-linux-gnu/libheimbase.so.1 (0x00007f1720c24000)
libhx509.so.5 => /usr/lib/x86_64-linux-gnu/libhx509.so.5 (0x00007f17209da000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f17207a2000)

and for ldd /usr/lib/x86_64-linux-gnu/libcurl.so.4

 linux-vdso.so.1 (0x00007ffc3f78e000)
libnghttp2.so.14 => /usr/lib/x86_64-linux-gnu/libnghttp2.so.14 (0x00007fdef9540000)
libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0 (0x00007fdef9323000)
librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1 (0x00007fdef9107000)
libpsl.so.5 => /usr/lib/x86_64-linux-gnu/libpsl.so.5 (0x00007fdef8ef9000)
libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007fdef8c6c000)
libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007fdef87a1000)
libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007fdef8556000)
libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007fdef8304000)
liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007fdef80f6000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fdef7ed9000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fdef7cba000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdef78c9000)
libunistring.so.2 => /usr/lib/x86_64-linux-gnu/libunistring.so.2 (0x00007fdef754b000)
libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007fdef71e5000)
libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 (0x00007fdef6fb1000)
libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x00007fdef6d7b000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fdef6afa000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fdef68f6000)
libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007fdef6620000)
libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007fdef63ee000)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007fdef61ea000)
libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007fdef5fdf000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fdef5dc4000)
libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007fdef5ba9000)
libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3 (0x00007fdef5968000)
/lib64/ld-linux-x86-64.so.2 (0x00007fdef99e4000)
libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007fdef5639000)
libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007fdef5426000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007fdef5222000)
libheimntlm.so.0 => /usr/lib/x86_64-linux-gnu/libheimntlm.so.0 (0x00007fdef5019000)
libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26 (0x00007fdef4d8c000)
libasn1.so.8 => /usr/lib/x86_64-linux-gnu/libasn1.so.8 (0x00007fdef4aea000)
libhcrypto.so.4 => /usr/lib/x86_64-linux-gnu/libhcrypto.so.4 (0x00007fdef48b4000)
libroken.so.18 => /usr/lib/x86_64-linux-gnu/libroken.so.18 (0x00007fdef469e000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fdef4496000)
libwind.so.0 => /usr/lib/x86_64-linux-gnu/libwind.so.0 (0x00007fdef426d000)
libheimbase.so.1 => /usr/lib/x86_64-linux-gnu/libheimbase.so.1 (0x00007fdef405e000)
libhx509.so.5 => /usr/lib/x86_64-linux-gnu/libhx509.so.5 (0x00007fdef3e14000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007fdef3b0b000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007fdef38d3000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fdef3535000)

So both still contain this line:

libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007fdef71e5000)

[astrada]

I don't know if it can be a problem. But the output of pmap by default shows the virtual address space occupation. I don't know if it's a reliable source, maybe it would be better to look at RSS/private memory.