Memory continually used up until Linux-OOM triggered

[pbutler747-collab]

Distribution

Mint 22.3

Package version

Nemo 6.6.3

Frequency

Quite often

Bug description

This issue keeps happening to me. I am trying to organize a bunch of photos (hundreds). I open up two nemo windows. I am moving/copying/replacing photos from the first window into various directories of the second window. I am scrolling through many different directories while doing this, all of which load previews of hundreds of photos). As I do all this, the free memory in the system contibually drops. Over the course of an hour or two the 16 GB on my otherwise idle system gets used up, until things start to hiccup and the kernel invokes the OOM-killer. If I kill the nemo windows, the memory all returns and the system stops hiccupping. I have no other apps running, except (sometimes) music playing from youtube. That is all. I understand that loading hundreds (or thousands) of photo previews uses up a lot of memory, but that should only be cached, and not lead to a OOM-killer situation. As it stands my only recourse is to kill the nemo windows every hour or two and prevent the issue from occurring. I am totally willing to compile a debug version of nemo and run it via valgrind (or similar) and reproduce the issue if need be but wanted to reach out first. I captured the /proc/PID/status of nemo right when the OOM was about to get triggered (see below). Notice the 16 GB of used VM space. (Machine has 16 GB installed).

Name: nemo
Umask: 0002
State: D (disk sleep)
Tgid: 98651
Ngid: 0
Pid: 98651
PPid: 3250
TracerPid: 0
Uid: 1000 1000 1000 1000
Gid: 1000 1000 1000 1000
FDSize: 64
Groups: 4 24 27 30 46 115 135 137 1000
NStgid: 98651
NSpid: 98651
NSpgid: 2933
NSsid: 2933
Kthread: 0
VmPeak: 15956704 kB
VmSize: 15948508 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 13529144 kB
VmRSS: 13519384 kB
RssAnon: 13502036 kB
RssFile: 2036 kB
RssShmem: 15312 kB
VmData: 14915476 kB
VmStk: 132 kB
VmExe: 1080 kB
VmLib: 32156 kB
VmPTE: 29440 kB
VmSwap: 1329576 kB
HugetlbPages: 0 kB
CoreDumping: 0
THP_enabled: 1
untag_mask: 0xffffffffffffffff
Threads: 7
SigQ: 0/62454
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000001001000
SigCgt: 0000000100000000
CapInh: 0000000800000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000
NoNewPrivs: 0
Seccomp: 0
Seccomp_filters: 0
Speculation_Store_Bypass: thread vulnerable
SpeculationIndirectBranch: conditional enabled
Cpus_allowed: fffff
Cpus_allowed_list: 0-19
Mems_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
Mems_allowed_list: 0
voluntary_ctxt_switches: 331050
nonvoluntary_ctxt_switches: 10143
x86_Thread_features:
x86_Thread_features_locked:

Steps to reproduce

As per description above. Most likely necessary to have multiple (hundreds) of directories, each with hundreds of photos.

Expected behavior

Linux OOM-killer should not have to be invoked just from using nemo, no matter how long the window is kept open and how many directories I scroll through.

Additional information

No response