I'm going to mark this bug as Private because nobody other than Chris
should be commenting right now. And the bug should be allowed to expire
if no more relevant comments are added.
Everyone else, if you experience any leaks then please open a new bug by
running:
ubuntu-bug gnome-shell
and
In Ubuntu 20.04 (with the newest packages) the leak is present. After
logging in the memory usage of gnome-shell is 208MB. After pushing
Super+A it jumps to 213MB and stay there. After lock/unlock the screen
it jumps to 270MB and stays there. Repeated Super+A and lock/unlock
seems to do no further
Since the recent gnome-shell (and related packages) update to
3.34.3-1ubuntu1~19.10.1 it seems like the uncontrollable memory leak is
gone for me. I wonder if @raof can confirm it fixed or not
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Anyone other than Chris please be sure to log your own bugs about memory
usage. Don't subscribe to this bug as it is incomplete and intended to
be just about whatever issue Chris is facing.
** Bug watch removed: gitlab.gnome.org/GNOME/gjs/issues #52
https://gitlab.gnome.org/GNOME/gjs/issues/52
Could be any connection between https://gitlab.gnome.org/GNOME/gjs/issues/52
and the problem here? (I am not an expert)
** Bug watch added: gitlab.gnome.org/GNOME/gjs/issues #52
https://gitlab.gnome.org/GNOME/gjs/issues/52
--
You received this bug notification because you are a member of
Using a wrapper script for gnome-shell actually breaks things, because
now systemd thinks the wrong process is sending ready signals
(everything starts up fine, but then gets killed after 10 seconds once
systemd decides its timed out).
And the problem is that all the processes inherit their
And to avoid affecting all other programs, instead of 'export' try
moving gnome-shell to gnome-shell.bin and creating a gnome-shell script
to set up the environment.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Maybe I gave the wrong advice. Try: HEAP_PROFILE_ONLY_MMAP=true
I know that once you successfully have that set then the performance
overhead goes away.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Hm. The gperftools profiler appears to have a catastrophic performance
impact on gnome-shell - it takes multiple minutes to go from login
screen to an idle desktop (there's also the problem that setting the
environment variable means *all* programs in the session profiled,
because they're all
A note for anyone finding this that if you have installed
AppImageLauncher then see bug #1862910.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1856516
Title:
Excessive memory usage by gnome-shell
Thanks for your efforts...
heaptrack_gui is telling me the largest peak allocation location is
either 60MB or 106MB, depending on what tab you look at. So that's not
evident of any leaks in the heap.
If your RSS was 1.6GB then that is still evident of a major leak or
bloat. The fact that
I expect that's an artifact of gnome-shell (and hence heaptrack) being
killed during session logout. The data's still there; heptrack_gui
heaptrack.gnome-shell.bin.10049.gz will view it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Thanks, but can you attach it again?...
$ gunzip heaptrack.gnome-shell.bin.10049.gz
gzip: heaptrack.gnome-shell.bin.10049.gz: unexpected end of file
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Here's a heaptrack trace of a gnome-shell session; I logged out one
gnome-shell hit 1.6GB RSS. Hopefully this is useful, or could point to a
specific thing to test.
** Attachment added: "Heaptrack trace of gnome-shell session"
** Tags added: leak
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1856516
Title:
Excessive memory usage by gnome-shell in 19.10
To manage notifications about this bug go to:
Reported bug #1862910
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1856516
Title:
Excessive memory usage by gnome-shell in 19.10
To manage notifications about this bug go to:
Unfortunately when I run ubuntu-bug gnome-shell it collects the
information but then when I tell it to send it just returns to the
command line immediately rather than sending me to launchpad, so I will
have to get that sorted first.
--
You received this bug notification because you are a member
I understand a few people are encountering memory usage problems. But to
prevent this from being an open-ended bug with multiple causes that
never gets fully closed, I suggest everyone logs their own new bugs.
Please run:
ubuntu-bug gnome-shell
to open a new bug and put your comments there.
I just spent the day researching this only to discover it's an ongoing
bug which is several years old.
I outline my results here: https://forum.level1techs.com/t/ubuntu-19-10
-gnome-shell-memory-leak/153376
To summarize that post, simply moving windows and toggling workspaces
causes gnome-shell
I don't know whether a problem I have is related to this issue or not. On one
of my machines which has been upgraded over several years and is now running
19.10 just one of the configured users is seeing a dramatic leak in
gnome-shell, even when nothing is happening on the UI. Immediately
I wonder if this is just the leftover smaller leaks we didn't manage to
totally fix in bug 1815550. To test that we'd probably need you to
exclude gnome-shell-extension-desktop-icons for a while. Sorry I don't
have suggestions for how to do that cleanly right now :/
Maybe just check to see if
OTOH this bug could stay open forever if we don't have agreement and
confirmation about what triggers the memory usage. So let it expire if
we don't find that.
** No longer affects: gnome-shell
** Bug watch removed: gitlab.gnome.org/GNOME/gnome-shell/issues #2061
** Changed in: gnome-shell
Status: Unknown => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1856516
Title:
Excessive memory usage by gnome-shell in 19.10
To manage notifications about
Vague bugs like gnome-shell#2061 are probably too risky to link to.
There's a reasonable chance the reporter of that bug is experiencing a
different leak to the reporter of this bug. Especially when the test
case to reliably reproduce the leak is not yet agreed on.
--
You received this bug
That said, if we do link to that upstream bug then at least we will get
notifications and avoid duplicate LP bugs linking to it...
** Also affects: gnome-shell via
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2061
Importance: Unknown
Status: Unknown
--
You received this bug
So, for reference: things which *don't* seem to (immediately) increase memory
useage:
*) Powering up the discrete GPU
*) Super-A / Super
*) Locking/unlocking the session.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Maybe the same as https://gitlab.gnome.org/GNOME/gnome-shell/issues/2061
? Although that has no more useful information than here.
** Bug watch added: gitlab.gnome.org/GNOME/gnome-shell/issues #2061
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2061
--
You received this bug notification
This laptop *does* have a secondary GPU. Interesting.
I *did* test whether firing up the secondary GPU resulted in memory
increase, and it didn't seem to. *But* I don't think texture memory and
KMS framebuffers are exposed as RSS anyway, so this leak would have been
serious, but hidden.
I wonder
Though I'm only assuming you're still a fan of secondary GPUs.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1856516
Title:
Excessive memory usage by gnome-shell in 19.10
To manage notifications
Just noticed a fix for a concerning leak in the Wayland case here:
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1011
That's fixed in mutter 3.34.4 and 3.35.4.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Though I'm only assuming you're still a fan on secondary GPUs.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1856516
Title:
Excessive memory usage by gnome-shell in 19.10
To manage notifications
At the end of December I remember popey wanted to focus on 'Super' or
'Super-A' leaks so it makes sense to move that into bug 1856838 given
there's some agreement on the test case there...
** Bug watch removed: gitlab.gnome.org/GNOME/gnome-shell/issues #1886
This bug is now entirely Chris' again :)
We still need some idea of a test case though, so Incomplete.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1856516
Title:
Excessive memory usage by
So, the X11 session is now up to 4526M/906M/107M, so it would seem that
there is at least one bug that applies to X11 and one that applies to
Wayland; possibly the same bug :)
I don't think that I can reproduce the “Super-A leaks 50MB” bug.
Repeatedly pressing that doesn't appear to result in any
Incomplete per comment #4. We need to all agree on a use case/test case
that triggers the issue reliably and then can focus on that.
** Changed in: gnome-shell (Ubuntu)
Status: Confirmed => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
This may have been fixed by
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/799.
See also https://gitlab.gnome.org/GNOME/gnome-shell/issues/1886 and
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1850201
FWIW, my gnome-shell has leaked to 3.4GB in 10 days. :(
** Bug
For the moment this bug is a place where we can discuss and find
possible causes. I expect there to be multiple.
So what we need first is some kind of test which is indicative of a leak
independent of the user. One that other people can reproduce and
automate. Not just /using/ the desktop in our
For comparison, I've run an GNOME-Shell-X11 session for 3577M/725M/99M
Virt/RSS/Shr after a comparable time period; this doesn't significantly
decrease after closing all the windows.
Although that's lower than the Wayland case, maybe it's starting to look
like it also has a slow leak?
--
You
38 matches
Mail list logo
