GDM: Memory leak in .gnome-shell-real process

  • Done
  • quality assurance status badge
Details
7 participants
  • Jan Nieuwenhuizen
  • Julien Lepiller
  • Leo Famulari
  • Ludovic Courtès
  • Luis Felipe
  • sirgazil
  • zimoun
Owner
unassigned
Submitted by
sirgazil
Severity
important
Merged with
S
S
sirgazil wrote on 18 Mar 2020 15:18
(name . bug-guix)(address . bug-guix@gnu.org)
170ee024512.c9ac6ac476703.6325608537898017895@zoho.com
I can't use GNOME anymore because of the problem I explained in the following thread:


On recent system upgrades, the problem got worse. Before, I could get to the end of the day despite the leak; but now it takes around 3 hours for the .gnome-shell-real process run by the gdm user to eat the remaining RAM.

It seems that the bug is stronger in the GNOME desktop, but I've seen, at least once, .gnome-shell-real using an abnormal amount of RAM while in sway (about 800 MiB).

My current guix:

$ guix describe
Generation 61 Mar 15 2020 08:44:39 (current)
sirgazil-x 8274cd7
branch: master
commit: 8274cd78f9f6d58e00e057a0eabe58e4e143cc4d
guix a431a63
branch: master
commit: a431a63537c8103b2a58c9a55d90184fb5c90361


---
L
L
Ludovic Courtès wrote on 18 Mar 2020 16:09
87a74d8zsq.fsf@gnu.org
Hi sirgazil,

sirgazil via Bug reports for GNU Guix <bug-guix@gnu.org> skribis:

Toggle quote (6 lines)
> I can't use GNOME anymore because of the problem I explained in the following thread:
>
> https://lists.gnu.org/archive/html/help-guix/2020-02/msg00206.html
>
> On recent system upgrades, the problem got worse. Before, I could get to the end of the day despite the leak; but now it takes around 3 hours for the .gnome-shell-real process run by the gdm user to eat the remaining RAM.

Ouch.

Toggle quote (2 lines)
> It seems that the bug is stronger in the GNOME desktop, but I've seen, at least once, .gnome-shell-real using an abnormal amount of RAM while in sway (about 800 MiB).

Could you check if it happens in a VM? That is, you build your GNOME
config with ‘guix system vm’, try to do some activity in the VM, and
check in top whether ‘gnome-shell’ is growing.

Thanks,
Ludo’.
J
J
Julien Lepiller wrote on 18 Mar 2020 17:09
4F9A8305-EA95-44E5-825D-F0C9FB5B1705@lepiller.eu
Le 18 mars 2020 10:18:11 GMT-04:00, sirgazil via Bug reports for GNU Guix <bug-guix@gnu.org> a écrit :
Toggle quote (31 lines)
>I can't use GNOME anymore because of the problem I explained in the
>following thread:
>
>https://lists.gnu.org/archive/html/help-guix/2020-02/msg00206.html
>
>On recent system upgrades, the problem got worse. Before, I could get
>to the end of the day despite the leak; but now it takes around 3 hours
>for the .gnome-shell-real process run by the gdm user to eat the
>remaining RAM.
>
>It seems that the bug is stronger in the GNOME desktop, but I've seen,
>at least once, .gnome-shell-real using an abnormal amount of RAM while
>in sway (about 800 MiB).
>
>My current guix:
>
>$ guix describe
>Generation 61 Mar 15 2020 08:44:39 (current)
> sirgazil-x 8274cd7
> repository URL: https://gitlab.com/sirgazil/guix-channel-x.git
> branch: master
> commit: 8274cd78f9f6d58e00e057a0eabe58e4e143cc4d
> guix a431a63
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: a431a63537c8103b2a58c9a55d90184fb5c90361
>
>
>---
>https://sirgazil.bitbucket.io/

I'm also hit by that bug. I do not use gnome though, and the .gnome-session-real process is owned by gdm. Ram usage is at around 200MB when starting and after a few days (putting the laptop to sleep during the night), it got to 2.4GB, even though I don't really need or use it beside logging in. After another restart, it was at 600MB after a day. That memory usage is ridiculous :/
S
S
sirgazil wrote on 18 Mar 2020 17:10
(name . "Ludovic Courtès")(address . ludo@gnu.org)(name . 40116)(address . 40116@debbugs.gnu.org)
170ee6964e3.ee395bf578532.436612750827795239@zoho.com
---- On Wed, 18 Mar 2020 10:09:57 -0500 Ludovic Courtès <ludo@gnu.org> wrote ----

[...]

> > It seems that the bug is stronger in the GNOME desktop, but I've seen, at least once, .gnome-shell-real using an abnormal amount of RAM while in sway (about 800 MiB).
>
> Could you check if it happens in a VM? That is, you build your GNOME
> config with ‘guix system vm’, try to do some activity in the VM, and
> check in top whether ‘gnome-shell’ is growing.

I can try, but last time I did something like that the VM with GNOME was too slow to do anything (this computer only has 4 GiB of RAM).
S
S
sirgazil wrote on 19 Mar 2020 19:13
GDM: Memory leak in .gnome-shell-real process
(name . 40116)(address . 40116@debbugs.gnu.org)
170f4001961.121b1861f95704.959508865105831753@zoho.com
I tried a virtual machine with my system configuration during 4 hours and couldn't reproduce the leak (I used "guix system vm"). ".gnome-shell-real" kept using about 260 MiB of RAM and it actually went down to 220 at some point.

In 4 hours, in my real system, the leak would have been visible.

I'm planning to create another virtual machine with "guix system vm-image" instead to install all the packages I have in my user profile and leave it running overnight to see if there is any difference.
L
L
Ludovic Courtès wrote on 21 Mar 2020 23:17
control message for bug #40116
(address . control@debbugs.gnu.org)
87o8spwdxa.fsf@gnu.org
severity 40116 important
quit
S
S
sirgazil wrote on 22 Mar 2020 01:38
GDM: Memory leak in .gnome-shell-real process
(name . 40116)(address . 40116@debbugs.gnu.org)
170ffad747a.106091f62126832.5365987086606508641@zoho.com
Toggle quote (2 lines)
> I'm planning to create another virtual machine with "guix system vm-image" instead to install all the packages I have in my user profile and leave it running overnight to see if there is any difference.

I wasn't able to create the VM image with this method. After an hour, the image was still building. I interrupted the process and gave up.
S
S
sirgazil wrote on 23 Mar 2020 18:01
(name . 40116)(address . 40116@debbugs.gnu.org)
17108574fb7.db28f889144585.6378115481300336402@zoho.com
I experience the same as Julien yesterday in a computer reconfigured with sway (no GNOME), but still using GDM. Here's a screenshot of "top" with gdm's .gnome-shell-real using 2.5 GiB of RAM:


I'm currently trying other other desktop environments in combination with slim login manager to work around the issue.
S
S
sirgazil wrote on 24 Mar 2020 14:15
(name . 40116)(address . 40116@debbugs.gnu.org)
1710caf15a3.c9b79ba71277.7628294219802776739@zoho.com
Toggle quote (2 lines)
> I'm currently trying other other desktop environments in combination with slim login manager to work around the issue.

I've been using a configuration with SLiM and GNOME for more than 20 hours with no leaks.
J
J
Jan Nieuwenhuizen wrote on 29 Mar 2020 18:08
(name . Ludovic Courtès)(address . ludo@gnu.org)
87ftdrta8e.fsf@gnu.org
Ludovic Courtès writes:

Toggle quote (18 lines)
> Hi sirgazil,
>
> sirgazil via Bug reports for GNU Guix <bug-guix@gnu.org> skribis:
>
>> I can't use GNOME anymore because of the problem I explained in the following thread:
>>
>> https://lists.gnu.org/archive/html/help-guix/2020-02/msg00206.html
>>
>> On recent system upgrades, the problem got worse. Before, I could get to the end of the day despite the leak; but now it takes around 3 hours for the .gnome-shell-real process run by the gdm user to eat the remaining RAM.
>
> Ouch.
>
>> It seems that the bug is stronger in the GNOME desktop, but I've seen, at least once, .gnome-shell-real using an abnormal amount of RAM while in sway (about 800 MiB).
>
> Could you check if it happens in a VM? That is, you build your GNOME
> config with ‘guix system vm’, try to do some activity in the VM, and
> check in top whether ‘gnome-shell’ is growing.

That looks like an upstream problem


are we going to investigate backporting a fix?

janneke

--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com| Avatar® http://AvatarAcademy.com
J
J
Jan Nieuwenhuizen wrote on 29 Mar 2020 18:10
(name . Ludovic Courtès)(address . ludo@gnu.org)
87blofta4l.fsf@gnu.org
Jan Nieuwenhuizen writes:

Toggle quote (4 lines)
> That looks like an upstream problem
>
> https://gitlab.gnome.org/GNOME/gnome-shell/issues/64

Sorry, this is not helping.

--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com| Avatar® http://AvatarAcademy.com
L
L
Leo Famulari wrote on 15 May 2020 19:13
(no subject)
(address . control@debbugs.gnu.org)
20200515171354.GA25761@jasmine.lan
severity 41215 important
merge 41215 40116
L
L
Luis Felipe wrote on 1 Oct 2020 17:56
GDM: Memory leak in .gnome-shell-real process
(name . 40116@debbugs.gnu.org)(address . 40116@debbugs.gnu.org)
9_w3QmEl8Zd9v1Qsnj126QVCwVyfQeqMjMPGRjmjJVD_6Oz7sNjj6y7h6LKvl2B2HW4yvmyzPXBDbEtB4E6SXhsTlAz58IbUYMR0N7A2xBQ=@protonmail.com
I've been using GDM again for 8 days now, and I don't see the leak anymore.

(Using guix 97e98e2)

---
Luis Felipe López Acevedo
Attachment: file
Z
Z
zimoun wrote on 23 Mar 2022 12:35
Re: bug#41215: memory leak in gnome-shell
(name . sirgazil)(address . sirgazil@zoho.com)
86wngkzyss.fsf@gmail.com
Hi,

On Wed, 18 Mar 2020 at 09:18, sirgazil <sirgazil@zoho.com> wrote:

Toggle quote (2 lines)
> I can't use GNOME anymore because of the problem I explained in the following thread:

[...]

Toggle quote (3 lines)
> $ guix describe
> Generation 61 Mar 15 2020 08:44:39 (current)

What is the status of this old bug [1]? Especially since the last merge
of core-updates.




Cheers,
simon
L
L
Luis Felipe wrote on 23 Mar 2022 16:13
(name . zimoun)(address . zimon.toutoune@gmail.com)
Sw6_lvAJLpt_jWSh15ZkjfOfZuedhmMqPU4gKkruJWueFJ_m13ItHIviJcciGq5gM-4PO0sgVacvaMqmV3ZzJilqaXs_7QLdvMgH6gBsDec=@protonmail.com
Hi zimoun,

On Wednesday, March 23rd, 2022 at 11:35 AM, zimoun <zimon.toutoune@gmail.com> wrote:
Toggle quote (4 lines)
>

> What is the status of this old bug [1]? Especially since the last merge

At least on my side (I'm sirgazil), the status remains the same: this is not an issue anymore.

I didn't close the issue, though, because I wanted to hear from other people affected by it first.

So, if Julien and Arne, for example, don't experience the issue anymore, I'm happy to close the issue.
Attachment: signature.asc
Z
Z
zimoun wrote on 23 Mar 2022 16:46
(name . Luis Felipe)(address . luis.felipe.la@protonmail.com)
CAJ3okZ1_KNLF+Z_JNaQ9rQ14GTEE9cvhXZ_rvG77Jw-WuvXX0g@mail.gmail.com
Hi Luis,

On Wed, 23 Mar 2022 at 16:13, Luis Felipe <luis.felipe.la@protonmail.com> wrote:

Toggle quote (2 lines)
> So, if Julien and Arne, for example, don't experience the issue anymore, I'm happy to close the issue.

Let wait 15 days and if no answer, let assume it is not an issue and
close it. :-)

Thank you for your feedback.

Cheers,
simon
J
J
Julien Lepiller wrote on 23 Mar 2022 17:00
C4582435-0768-469F-8DB1-3F52B1B1D59F@lepiller.eu
On March 23, 2022 4:46:53 PM GMT+01:00, zimoun <zimon.toutoune@gmail.com> wrote:
Toggle quote (17 lines)
>Hi Luis,
>
>On Wed, 23 Mar 2022 at 16:13, Luis Felipe <luis.felipe.la@protonmail.com> wrote:
>
>> So, if Julien and Arne, for example, don't experience the issue anymore, I'm happy to close the issue.
>
>Let wait 15 days and if no answer, let assume it is not an issue and
>close it. :-)
>
>Thank you for your feedback.
>
>Cheers,
>simon
>
>
>

I haven't had that issue in a while, I tgink we can close.
L
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 40116@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 40116
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch