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

Even native programs are moving towards web tech, for eg GNOME shell is written in JavaScript and the PolicyKit component of the GNU/Linux desktop world uses JavaScript as a scripting language to define policies in. Of course there are Electron/Tauri apps for wrapping web tech in a native porting layer.


> eg GNOME shell is written in JavaScript

Is that some way related to why almost every GNOME shell extension is a memory hog (due to memory leaks?), I was fed up of replacing shell extensions in the hope of finding better one and finally disabled shell extensions altogether.

I've hardly had any GNOME crash after disabling shell extensions.

P.S. Congratulations on the launch, OP. Seems like a very useful too, Would try to play with it later.


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: