Ringboard EGUI uses a lot of shared memory

[PennyJim]

I find my memory usage climbing slowly as i use it, and it took me a long while to actually identify Ringboard as the culprit

I had assumed it was, because it was the only recent change, but because I was trying to sort by memory and it wasn't appearing I thought it couldn't be it. Only to finally search for ringboard in resource monitor, and find it having a massive amount of shared memory

Killing it, I found my 32gb memory usage dropped drastically:

The only thing I could think of being my fault, is the fact that I copy a lot of images. In fact, my screenshot tool (GNOME) automatically puts screenshots into my clipboard.
I would still hope it would have some way of cleaning its memory, because it just feels like it has a bad leak right now.

[SUPERCILEX]

Whoa, yeah that's really bad. I'll see if I can repro. What version of ringboard egui is this? Should be in the title bar.

[PennyJim]

V0.8.1

[SUPERCILEX]

Do you leave the gui open all the time? If you close it I see the memory drop, but if I leave it open and copy stuff till images disappear from the bottom I'm seeing that they're not being cleaned up. I'll fix that, but just wondering if that's the bug you're seeing.

[PennyJim]

I don't even intentionally leave it open. There's a chance that I've done it from time to time, but I don't think that's the whole reason....?

I, in fact, barely open it... The ways I know to close it are to press escape, click the close button, or press enter on an entry.
The other thing I'm constantly doing is copying links as I send people links to the documentation while helping them make factorio mods.

Maybe it's related to how you send it to the background instead of killing it?
How exactly did you force it to occur? Because I've only had it happen slowly over the course of a couple days. Even spamming full-two-2k-screen screenshots don't get it to spike. I did notice the fit-to-screen'ness seems to have an offset that builds in each subsequent entry, but that's another (less important) bug report

This might just be a thing where I need to try dumping the memory the next time I catch it (does dumping memory with gcore also include shared memory?)

[PennyJim]

To be more clear on why I don't think it is (because as I rambled on writing that I tested and found additional reason to not think it), it made the normal memory build a lot, but closing it would flush it properly.

[SUPERCILEX]

The ways I know to close it are to press escape, click the close button, or press enter on an entry.

Yeah all of that drops the memory usage in my testing.

How exactly did you force it to occur?

The easiest way is to press Alt+M and then search for "image". Then if you press Esc to go back to the main list, the memory won't drop.

But! I fixed this bug and noticed the memory doesn't drop all the way back to zero. So there's some kind of memory leak in egui.

[PennyJim]

I didn't know you could do alt-m to search by MIME type. Sounds like a thing that's missing from the EGUI README.md :p

But also, good luck finding your memory leak. I've never managed memory myself so that sounds awful to find and fix

[SUPERCILEX]

Oops, added: b201bf8

[SUPERCILEX]

Yeah, I'm going to see if I can trace the leak.

In the meantime, you can run XDG_CURRENT_DESKTOP=i3 cargo +nightly install clipboard-history-egui --no-default-features --features $XDG_SESSION_TYPE to disable daemon mode (so closing egui actually kills it instead of leaving it open in the background). Oh and you'll have to kill the existing ringboard-egui instance.

[PennyJim]

That worked 👍 (after adding --force)

[SUPERCILEX]

Well I filed emilk/egui#5600, but I'm not sure it's worth debugging this further. At some point I'd like to get rid of egui and build a libcosmic iced application, though that won't be for a while.