Memory leak leading to high RAM usage

[igormp]

 * Nemo version
    3.8.2
 * Is issue with desktop or windowed nemo?
    Windowed
 * Distribution
    Arch Linux
 * Graphics hardware *and* driver used
    Intel® HD Graphics 4400, i915
 * 32 or 64 bit
    64 bit

Issue High memory usage after a couple of hours with Nemo open.

Steps to reproduce Open Nemo and leave it idling for a couple hours.

Other information Plugin list:

/usr/lib/nemo/nemo-extensions-list
    NEMO_EXTENSION:::NemoShare:::Nemo Share:::Allows you to quickly share a folder from the context menu
    NEMO_EXTENSION:::NemoFileRoller:::Nemo Fileroller:::Allows managing of archives from the context menu

This issue is probably related to #1101

I'll gladly provide any further needed info.

[leigh123linux]

Does it still leak if the share extension is disabled?

[leigh123linux]

cc: @eli-schwartz

[igormp]

Does it still leak if the share extension is disabled?

Yes, it does. I just disabled both extensions and left it running for 20 minutes, the memory usage is already at 250MiB.

[leigh123linux]

Is it the same with all extensions disabled? Can you post the output for env

env

[igormp]

Is it the same with all extensions disabled?

Yes.

env
XDG_SEAT=seat0
LANG=en_US.UTF-8
DISPLAY=:0
NLS_LANG=AMERICAN_AMERICA.AL32UTF8
LC_CTYPE=en_US.UTF-8
XDG_VTNR=1
INVOCATION_ID=9945facfd09d4af4b91cb2b68ca10640
ORACLE_SID=XE
PWD=/home/igor
MOZ_PLUGIN_PATH=/usr/lib/mozilla/plugins
XAUTHORITY=/home/igor/.Xauthority
SHLVL=3
JOURNAL_STREAM=9:24671
LOGNAME=igor
COLORTERM=truecolor
XDG_SESSION_ID=c1
GOPATH=/home/igor/.go
LESS=-R
ORACLE_HOME=/usr/lib/oracle/product/11.2.0/xe
GNOME_DESKTOP_SESSION_ID=this-is-deprecated
WINDOWPATH=1
LC_MEASUREMENT=pt_BR.UTF-8
LC_PAPER=pt_BR.UTF-8
LC_NUMERIC=pt_BR.UTF-8
ZSH=/home/igor/.oh-my-zsh
LC_MONETARY=pt_BR.UTF-8
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
VTE_VERSION=5201
MAIL=/var/spool/mail/igor
GTK_OVERLAY_SCROLLING=1
SHELL=/usr/bin/zsh
OLDPWD=/home/igor
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:
LC_TIME=pt_BR.UTF-8
TERM=xterm-256color
SESSION_MANAGER=local/Atlas:@/tmp/.ICE-unix/1647,unix/Atlas:/tmp/.ICE-unix/1647
PAGER=less
WINEARCH=win32
PATH=/home/igor/.gem/ruby/2.5.0/bin:/home/igor/.npm-global/bin:/home/igor/.gem/ruby/2.5.0/bin:/home/igor/.npm-global/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/android-sdk/platform-tools:/usr/lib/jvm/default/bin:/usr/lib/oracle/product/11.2.0/xe/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/bin:/home/igor/.go/bin:/bin:/home/igor/.go/bin
WINEPREFIX=/home/igor/.wine32/
HOME=/home/igor
VISUAL=vim
BROWSER=google-chrome-stable
LSCOLORS=Gxfxcxdxbxegedabagacad
XDG_RUNTIME_DIR=/run/user/1000
XDG_CURRENT_DESKTOP=X-Cinnamon
USER=igor
WINDOWID=90177539
_=/usr/bin/env

[JosephMcc]

Ok. So I'm not seeing this problem under Mint. One thing I noticed in your screenshot of the memory usage in the other issue is that nemo is also using a decent amount of cpu. That doesn't happen here either. It seems it doing something for you that it's not doing here.

[leigh123linux]

I don't see the issue in Fedora either.

[igormp]

Then it probably is a problem with Arch's build or something to do with my own installation? Seems weird, since other people reported similar issues. I'm going to try to spin up a Manjaro VM (which should be similar enough to Arch whilst being fresh) to try to reproduce this issue.

[mtwebster]

Can you disable thumbnails? Preferences->Preview->show thumbnails: Never

Is your ~/.cache folder redirected elsewhere?

[eli-schwartz]

I'm guessing your installation? I opened nemo over two hours ago now, and left it running in the background. You said this is enough to replicate the memory issue on your system.

I checked the memory, it's still using the same CPU/MEM it was when I first started it, which is 0% CPU, 0.3% MEM.

It's clearly more complicated than "oh, the stock configuration".

Also this was showing thumbnails for a couple PDF files at the time.

[igormp]

Can you disable thumbnails? Preferences->Preview->show thumbnails: Never

This actually solved the problem! Any idea on why?

Is your ~/.cache folder redirected elsewhere?

No, it's not, although it's a bit big (a bit over 20gb).

I'm guessing your installation?

Yeah, it seems to be the case. After creating a VM to try it out, I couldn't reproduce the issue either.

[mtwebster]

Usually the problem would be with permissions or some other factor preventing thumbnails from being successfully generated, but nemo is supposed to be smart enough not to keep trying after a couple of failures. Are the file/folder owner/group permissions ok under the .cache folder? I'm only interested really in thumbnails/*. They should all be user:user owned.

Please let me know if that's not the case.

Could you turn thumbnails back on (and I expect the issue to reappear) and if so, does the CPU usage persist even when navigating to other folders? Does it occur regardless of the open location? Does pressing F5 (this deletes the current location's thumbnails to force regeneration) do anything?

If you delete your ~/.cache/thumbnails does the problem go away?

Unfortunately, the most helpful way to obtain debugging specific to nemo thumbnails is a flag that needs changed in the code and rebuilt. I've just pushed a change to make this a runtime thing, so it could potentially be used to troubleshoot something like this in the future.

[igormp]

Are the file/folder owner/group permissions ok under the .cache folder?

They seem to be. Some of them are owned by user:user, while others are user:root.

I'm only interested really in thumbnails/*. They should all be user:user owned.

Yeah, those are all user:user.

Could you turn thumbnails back on (and I expect the issue to reappear) and if so, does the CPU usage persist even when navigating to other folders?

There's a CPU usage spike when browsing to a new folder, but after that it remains stable (no noticeable CPU or RAM usage).

Does it occur regardless of the open location?

It seems to only happen when at my home folder and some subfolders. It doesn't happen if I'm at /, as an example.

Does pressing F5 (this deletes the current location's thumbnails to force regeneration) do anything?

If I'm anywhere but my home folder, CPU and RAM usage spikes for a second while generating the thumbnails, but after that everything comes back to normal. On the other hand, if I'm at my home folder, it only reloads the thumbnails, with some CPU usage and a continuous increase in RAM usage.

If you delete your ~/.cache/thumbnails does the problem go away?

It actually did! Any idea on why this happened? I believe that the issue is now solved, thanks for all the help.

[dawid2193487]

I have this issue too and it already crashed my system 5 times. I will try removing the thumbnails.

[JoeKays]

High CPU usage in nemo and even higher for gnome-shell (yeah I'm using gnome, but Nautilus kind of gets worse with every patch). Deleted .cache/thumbnails and it is ok now. Must be still a bug though, as it works correctly with Nautilus.

[wkrueger]

Left my PC on and the next day the "nemo-desktop" process was eating 8 GiBs of RAM, on ubuntu 19 + budgie. Trying the thumbnail fix.

[saaj]

Same problem. nemo-desktop is frequently getting over 1 GiB when I notice and restart it (along side csd-color, but that's another story probably related to redshift that I use).

I've also removed the thumbnail directory, but just in case I'm letting monit make me forget about it ;-)

check process nemo-desktop matching "nemo-desktop"
  start program = "/bin/true"
  stop program = "/usr/bin/pkill nemo-desktop"

  if totalmem > 128 MB for 10 cycles then restart
  if does not exist then exec "/bin/true"

[Lanchon]

back from the dead...

why was this issue closed? deleting thumbnails is a workaround, not a fix.

i'm using linux mint 19.3 nemo 4.4.3 and im experiencing the issue. 5 GB or more of memory usage after a few days.

i deleted thumbnails, i'll see how nemo fares in the next few days. but AFAICT, permissions in thumbnails were ok.

thanks

[smurphos]

i'm using linux mint 19.3 nemo 4.4.3 and im experiencing the issue.

Then you really need to see if you can reproduce the problem on a current nemo version, as there has been a lot of development since 4.4.3 - (5.4 will in the soon to be available Mint 21 beta). If you can reliably make nemo 5.4 leak memory and can help the devs pinpoint a cause during the beta testing phase then it may well get fixed.