Possible memory leak on F43

I have been having this issues where after a few days of usage the base memory usage (everything is closed, even the system tray of apps like discord and slack is closed) of my PC is around 45%. This is causing cases where apps I’m activly using are getting force closed to avoid oom.

Just now I had all of my chrome windows force closed, when I woke up my computer from suspend, but this has happened also while using it.

System specs:

I can not see anything in htop that would be taking up this much memory. When I reboot, the base memory usage goes back to normal 1-3% like i would expect.

I did read about how swap is done with compressed memory and that actula page files are “bad“ and that sometimes file contents could be cached, and take up memory. But those cache files should be evicted first and not my apps so I’m not sure what is causing this mess….

Any help would be apreciated.

Are you sure it is being killed due to OOM? Are there system logs from systemd-oomd saying that it is killing processes due to memory pressure?

Found this in the logs:

It’s considerably easier if you post text as text, rather than as a screenshot of text. We can’t search, cut/paste or easily read screenshots. If you post as pre-formatted text, the formatting is also maintained and the entire rest of the site can index and search your output.

Heres the text as text:

Apr 29 20:26:14 GLaDOS kernel: Chrome_ChildIOT invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=200
Apr 29 20:26:14 GLaDOS kernel: CPU: 3 UID: 1000 PID: 23162 Comm: Chrome_ChildIOT Tainted: G        W           6.19.12-200.fc43.x86_64 #1 PREEMPT(lazy) 
Apr 29 20:26:14 GLaDOS kernel: Tainted: [W]=WARN
Apr 29 20:26:14 GLaDOS kernel: Hardware name: Micro-Star International Co., Ltd. MS-7C91/MAG B550 TOMAHAWK (MS-7C91), BIOS A.C0 03/06/2023
Apr 29 20:26:14 GLaDOS kernel: Call Trace:
Apr 29 20:26:14 GLaDOS kernel:  <TASK>
Apr 29 20:26:14 GLaDOS kernel:  dump_stack_lvl+0x5d/0x80
Apr 29 20:26:14 GLaDOS kernel:  dump_header+0x43/0x1b3
Apr 29 20:26:14 GLaDOS kernel:  oom_kill_process.cold+0xa/0xb5
Apr 29 20:26:14 GLaDOS kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
Apr 29 20:26:14 GLaDOS kernel:  out_of_memory+0xf2/0x290
Apr 29 20:26:14 GLaDOS kernel:  __alloc_pages_slowpath.constprop.0+0x875/0x9f0
Apr 29 20:26:14 GLaDOS kernel:  __alloc_frozen_pages_noprof+0x32f/0x350
Apr 29 20:26:14 GLaDOS kernel:  alloc_pages_mpol+0x86/0x190
Apr 29 20:26:14 GLaDOS kernel:  folio_alloc_noprof+0x5e/0xf0
Apr 29 20:26:14 GLaDOS kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
Apr 29 20:26:14 GLaDOS kernel:  __filemap_get_folio_mpol+0x1ee/0x330
Apr 29 20:26:14 GLaDOS kernel:  filemap_fault+0x112/0xcc0
Apr 29 20:26:14 GLaDOS kernel:  __do_fault+0x34/0x1d0
Apr 29 20:26:14 GLaDOS kernel:  do_read_fault+0x12b/0x260
Apr 29 20:26:14 GLaDOS kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
Apr 29 20:26:14 GLaDOS kernel:  ? handle_pte_fault+0x118/0x240
Apr 29 20:26:14 GLaDOS kernel:  do_fault+0x157/0x230
Apr 29 20:26:14 GLaDOS kernel:  __handle_mm_fault+0x45d/0x6f0
Apr 29 20:26:14 GLaDOS kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
Apr 29 20:26:14 GLaDOS kernel:  handle_mm_fault+0x10a/0x340
Apr 29 20:26:14 GLaDOS kernel:  do_user_addr_fault+0x2b4/0x7b0
Apr 29 20:26:14 GLaDOS kernel:  exc_page_fault+0x7e/0x1a0
Apr 29 20:26:14 GLaDOS kernel:  asm_exc_page_fault+0x26/0x30
Apr 29 20:26:14 GLaDOS kernel: RIP: 0033:0x55a8c3d74a80
Apr 29 20:26:14 GLaDOS kernel: Code: Unable to access opcode bytes at 0x55a8c3d74a56.
Apr 29 20:26:14 GLaDOS kernel: RSP: 002b:00007f50a6bfa8d8 EFLAGS: 00010246
Apr 29 20:26:14 GLaDOS kernel: RAX: 0000000000000000 RBX: 0000225400045680 RCX: 0000000000000000
Apr 29 20:26:14 GLaDOS kernel: RDX: 0000000000000001 RSI: 00007f50a6bfac08 RDI: 0000225400051000
Apr 29 20:26:14 GLaDOS kernel: RBP: 00007f50a6bfaf50 R08: 00002254000456a8 R09: 0000000000000053
Apr 29 20:26:14 GLaDOS kernel: R10: 0000000000000000 R11: 00007f50abdae000 R12: 00007f50a6bfa940
Apr 29 20:26:14 GLaDOS kernel: R13: 0000225400004540 R14: 00002254000456a8 R15: 0000225400004510
Apr 29 20:26:14 GLaDOS kernel:  </TASK>
Apr 29 20:26:14 GLaDOS kernel: Mem-Info:
Apr 29 20:26:14 GLaDOS kernel: active_anon:2583901 inactive_anon:2365410 isolated_anon:0
                                active_file:6558 inactive_file:25639 isolated_file:0
                                unevictable:91 dirty:583 writeback:285
                                slab_reclaimable:186119 slab_unreclaimable:172873
                                mapped:187504 shmem:361884 pagetables:90871
                                sec_pagetables:1026 bounce:0
                                kernel_misc_reclaimable:0
                                free:73666 free_pcp:15 free_cma:0
Apr 29 20:26:14 GLaDOS kernel: Node 0 active_anon:10335604kB inactive_anon:9461640kB active_file:26232kB inactive_file:102192kB unevictable:364kB isolated(anon):0kB isolated(file):0kB mapped:750016kB dirty:2332kB writeback:1140kB shmem:1447536kB shmem_thp:0kB shmem_pmdmapped:0kB anon_thp:4096kB kernel_stack:79168kB pagetables:36348>
Apr 29 20:26:14 GLaDOS kernel: Node 0 DMA free:11264kB boost:0kB min:28kB low:40kB high:52kB reserved_highatomic:0KB free_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB zspages:0kB present:15996kB managed:15360kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB f>
Apr 29 20:26:14 GLaDOS kernel: lowmem_reserve[]: 0 3186 31990 31990 31990
Apr 29 20:26:14 GLaDOS kernel: Node 0 DMA32 free:121324kB boost:0kB min:6292kB low:9320kB high:12348kB reserved_highatomic:0KB free_highatomic:0KB active_anon:1026524kB inactive_anon:714964kB active_file:928kB inactive_file:12924kB unevictable:48kB writepending:900kB zspages:28940kB present:3328996kB managed:3262852kB mlocked:48kB >
Apr 29 20:26:14 GLaDOS kernel: lowmem_reserve[]: 0 0 28804 28804 28804
Apr 29 20:26:14 GLaDOS kernel: Node 0 Normal free:162076kB boost:102400kB min:163656kB low:193140kB high:222624kB reserved_highatomic:2048KB free_highatomic:0KB active_anon:9309248kB inactive_anon:8746508kB active_file:25612kB inactive_file:89148kB unevictable:316kB writepending:1712kB zspages:2848740kB present:30133760kB managed:2>
Apr 29 20:26:14 GLaDOS kernel: lowmem_reserve[]: 0 0 0 0 0
Apr 29 20:26:14 GLaDOS kernel: Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 1*1024kB (U) 1*2048kB (M) 2*4096kB (M) = 11264kB
Apr 29 20:26:14 GLaDOS kernel: Node 0 DMA32: 163*4kB (UME) 123*8kB (UME) 123*16kB (UME) 370*32kB (UME) 332*64kB (UME) 229*128kB (UME) 121*256kB (UME) 17*512kB (UM) 9*1024kB (UM) 3*2048kB (UM) 0*4096kB = 121044kB
Apr 29 20:26:14 GLaDOS kernel: Node 0 Normal: 3021*4kB (UME) 11328*8kB (UME) 1171*16kB (UE) 923*32kB (UE) 146*64kB (UE) 3*128kB (U) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 160708kB
Apr 29 20:26:14 GLaDOS kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB
Apr 29 20:26:14 GLaDOS kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
Apr 29 20:26:14 GLaDOS kernel: 402174 total pagecache pages
Apr 29 20:26:14 GLaDOS kernel: 3785 pages in swap cache
Apr 29 20:26:14 GLaDOS kernel: Free swap  = 208kB
Apr 29 20:26:14 GLaDOS kernel: Total swap = 8388604kB
Apr 29 20:26:14 GLaDOS kernel: 8369688 pages RAM
Apr 29 20:26:14 GLaDOS kernel: 0 pages HighMem/MovableOnly
Apr 29 20:26:14 GLaDOS kernel: 176223 pages reserved
Apr 29 20:26:14 GLaDOS kernel: 0 pages cma reserved
Apr 29 20:26:14 GLaDOS kernel: 0 pages hwpoisoned
Apr 29 20:26:14 GLaDOS kernel: Memory cgroup min protection 256000kB -- low protection 0kB

Some extra info:
I still didn’t restart the PC but the memory usage after waking it up today went down to around 30% still not great but a bit better. Gonna have to restart it tho, so I can work.

From this I assume you are using Chrome as your browser that that it’s using a lot of memory.

You should be able to confirm by watching Chromes memory using in a tool like top.

Does chrome have tools to report on it’s memory usage by tab?

Shift-Esc will (probably) pull up the memory consumption for each tab within Chrome. It does on FireFox, so I assume Chrome will have something similar.

Maybe keep an eye on it and look for a runaway tab consuming more and more memory with poorly written Javascript.

There’s also memstrack which will track and display memory consumption on a process by process basis, just in case Chrome is being incorrectly fingered as the culprit by the OOM killer.

Yes I’m using chrome, but the whole issue is that even after I closed everything, i still had around 30-40% memory usage. So while chrome might have been the largest memory allocation out of the user apps, something else was still keeping almost 16gb of ram used. If that usage wasn’t there Chrome wouldn’t had to be murdered, it was just a victim and not the culprit in this case.

Not all memory will be accounted as free because of the way the kernel caches and optimises memory use. So the 30% may not be an issue.

You need to share the output free -h so we can judge if that is an issue.

Hi!
I ended up restarting the PC that day to get some work done. But it is back up to 38% RAM usage after a few days so I can run the command as you asked

[dpeter99@GLaDOS]~% free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        12Gi       3.9Gi       486Mi        16Gi        19Gi
Swap:          8.0Gi       2.6Gi       5.4Gi
[dpeter99@GLaDOS]~% 

I have also opened the chrome task manager but that looks fine, in this idle state.


And here is another htop of the current situation

Hit F5 in htop to go into tree display, and see what is spawning multiple copies of plasma-discover

In htop, you might want to configure (press [F2] button, → [DisplayOptions]) to Hide userland process threads as multiple threads of a process share the same memory space, therefore it is not relevant to display them more than once.

What you can see here is that plasma-discover takes 1GB of your RAM. This is not that surprising, GNOME Software is behaving in a similar way. As long as it keeps around that size and doesn’t grow much larger, I guess it is fine. If it is not, it would be necessary to debug that specific process.