Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've noticed the memory leaks too. Unfortunately I can't live without GNOME shell extensions and I need to reboot/logout for security updates every now and then, so I just got enough RAM to let me continue working while leaks are going on.


I was doing the same, But unexpected crashes due to OOM killing became too much to handle with 32GB memory.

I replaced the extensions I use with standalone applications and I've never been happier with GNOME. But its sad that the extensions ruin the experience of GNOME and possibly one of the main reasons for the hate it gets as a DE.


I have less RAM than that. I use psi-notify to get a warning when GNOME is starting to use too much RAM. That is usually early enough that I can close a few apps to avoid the crash, then logout/reboot to regain the RAM.

There is also a GNOME/FreeDesktop memory PSI notifier thing but it isn't in Debian yet.

https://gitlab.freedesktop.org/hadess/low-memory-monitor/ https://www.hadess.net/2019/12/gmemorymonitor-low-memory-mon... https://www.hadess.net/2019/08/low-memory-monitor-new-projec...

I really wish there was a way to debug where all the leakage is coming from, I don't think it has always been the case :(


You might know this, But for those who don't it's very easy to get the stack trace and debug GNOME (or any package) with Arch Linux now due to inclusion of debug packages via Debuginfod service[1] (From which the symbols are automatically downloaded when using gdb).

So for GNOME shell,

   coredumpctl gdb /usr/bin/gnome-shell

   (gdb) bt full

Then head on to GNOME's gitlab to post the issue, Only to be confronted by similar issues being open for past five years :P

P.S. I mean no offense to GNOME developers and contributors, I love GNOME and use it on all my devices(including phone!) but sometimes I wish they worked more on stability than creating under cooked mechanisms which abuses the system(GNOME extensions).

[1] https://wiki.archlinux.org/title/Debugging/Getting_traces


coredumpctl and gdb aren't very useful at debugging out-of-memory situations. I've had better luck running plasmashell under heaptrack (koute likes to advertise bytehound but it hasn't worked on the programs I tried it on, though I've never reported the bugs). Unfortunately heaptrack usually just indicates that allocations are coming from the QV4 JS engine (since plasmashell, like GNOME Shell, is written substantially in JS), rather than giving me a C++ stack trace. You can try heaptrack on GNOME Shell as well, but you may not have much better luck considering that shell extensions are written in JS (it's possible you'll get a usefully-sized C++ stack trace telling you what resource the JS code is leaking).


Thank you for sharing the information, I will be trying heaptrack.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: