Open HeroicMastodon opened 1 year ago
Can you try to revert to f866f1eea10144fa0ab60e107e6a0235667edc1b and reproduce? In case it is gone it might be, that some of the optimizations recently introduced introduced. We can tag the contributor, when we know that's related.
I reverted to f866f1e and I haven't been able to replicate the large memory spike. However, just before reverting, I noticed that xorg had climbed to 1g while idle. And just now, as I was trying to replicate the spike, it went up to 1g again, but this may be unrelated. I'm not convinced this fixed the issue because it doesn't happen consistently. But I will keep running on this commit and investigating over the next few days and post any updates.
Well, after leaving my pc idle for a few hours today, the ram got so high that my computer froze. There are at least two confounding factors here though. I am running Eww and dunst with leftwm, where I am not using those in my other two environments. Today, I will try isolating leftwm to see if the issue persists.
After a few more hours with dunst and eww disabled, I'm still having jumps in memory. I haven't reached crash levels again. The problem seems to be leftwm, I can't think of anything else that is different between the environments and I have never seen this before installing but I'm also not finding anything useful in the xorg logs that would indicate a problem.
Since reverting, I have not been able to replicate the spike when closing a window though. Right now the memory footprint just seems to randomly double in size every few hours.
Let me know if there is anything I can do to better diagnose the issue
Is there possibly another task, that is polling leftwm-state
? Are you running picom
? I vaguely remember a case, where picom caused some severe memory issues.
Which leftwm task is it exactly that is spiking?
Eww was polling the state, but running without eww didn't seem to make a difference. And now that I have re-enabled eww, I haven't seen anymore memory problems.
I am using Picom and I saw the other issue regarding it, but the fixes there didn't seem to make a difference either.
Leftwm itself doesn't seem to take up memory, but xorg does and it only seems to happen when I'm running leftwm. But the time and memory footprint seem random. Other than sometimes killing windows, I can't find a consistent trigger.
From the Picom issue, I remember mentions of PIXMAP errors and I have read that those can cause Xorg memory to increase over time, so maybe there is something to investigate there?
Would you mind killing picom and run a few hours without it?
Looks like it was Picom. I haven't had any issues since running without it. I also learned that my card/driver supports glx, and I don't have any issues running with that backend either. I am going to switch back to the current commit and make sure everything is still running smooth, before we close this one out. Thanks for all the help
Thanks for your testing.
If you want to report this to picom you could reference this issue. Then I would keep it open until that report will be solved. Otherwise I guess I would close this, if you find you are good after reverting to HEAD
.
Describe the bug
Occasionally killing a window using the CloseWindow command will be delayed and cause xorg memory usage to spike. On my system is usually hovers around 200mb but after killing a window I have had it spike to as high as 8gb. Soft reloading leftwm will sometimes completely fix the issue, but often results in only a small amount of memory reduction by xorg. Either way, the memory used by xorg remains high for the duration of the session. This only seems to happen on leftwm, and doesn't seem to happen on awesomewm nor pop os.
Expected behavior (optional)
No response
Steps to reproduce (optional)
No response
Relevant log output (optional)
No response
OS / Distro
Linux pop-os 6.2.6-76060206-generic #202303130630~1683753207~22.04~77c1465 SMP PREEMPT_DYNAMIC Wed M x86_64 x86_64 x86_64 GNU/Linux
Additional System Information (optional)
No response
LeftWM Check