3 ms·

> 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

> 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.

pabs3 4y ago
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.
- Abishek_Muthian 4y ago
  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.
  - pabs3 4y ago
    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://gitlab.freedesktop.org/hadess/low-memory-monitor/ https://www.hadess.net/2019/12/gmemorymonitor-low-memory-monitor-2nd.html https://www.hadess.net/2019/12/gmemorymonitor-low-memory-mon... https://www.hadess.net/2019/08/low-memory-monitor-new-project.html 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 :(
    - Abishek_Muthian 4y ago
      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 https://wiki.archlinux.org/title/Debugging/Getting_traces
      - nyanpasu64 4y ago
        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).
        Abishek_Muthian 4y ago
        Thank you for sharing the information, I will be trying heaptrack.

pabs3 4y ago

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.

Abishek_Muthian 4y ago
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.
- pabs3 4y ago
  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://gitlab.freedesktop.org/hadess/low-memory-monitor/ https://www.hadess.net/2019/12/gmemorymonitor-low-memory-monitor-2nd.html https://www.hadess.net/2019/12/gmemorymonitor-low-memory-mon... https://www.hadess.net/2019/08/low-memory-monitor-new-project.html 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 :(
  - Abishek_Muthian 4y ago
    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 https://wiki.archlinux.org/title/Debugging/Getting_traces
    - nyanpasu64 4y ago
      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).
      - Abishek_Muthian 4y ago
        Thank you for sharing the information, I will be trying heaptrack.