[SOLVED] Gnome 46 on X.Org crashes shortly after logging in

werefkin · 2024-04-01 09:29:46

seth wrote:

Have you tried "xterm -display :0" (or might now be :1 b/c GDM is on :0 )?
You can otherwise reliably start gnome and just let it sit there and do nothing for a long time?

am not 100% sure what you mean here
If I do not log in in the gdm, xterm cannot open netiher 0 nor 1 display. when i do "xterm -display :1" after log-in in GUI gdm, there are no errors, but the console is inaccesible. in the gnome session a corresponding xterm terminal appears.

seth wrote:

Edit: in that light, what do the crashes look like for that condition?

do you ask me for a journal for this case? it basically looks like that the app start to open, then nothing happens, then the corrupted window shortly appears.

seth · 2024-04-01 12:48:24

when i do "xterm -display :1" after log-in in GUI gdm, there are no errors, but the console is inaccesible. in the gnome session a corresponding xterm terminal appears.

That's what I wanted to know, also if you can eg. run nautlius etc. from that xterm and can make gnome crash that way.

do you ask me for a journal for this case?do you ask me for a journal for this case?

Yes, I'm curious whether that scenario looks more like all the other "gnome crasheson login" journals.

werefkin · 2024-04-01 13:30:37

Yes, I'm curious whether that scenario looks more like all the other "gnome crasheson login" journals.

here I added firefox to startup apps:
https://0x0.st/XzLv.txt

yurus · 2024-04-01 14:11:57

This issue also happens to me. If I open an app shortly after login the whole shell crashes.

I'm looking through the journal but couldn't find anything useful.

seth · 2024-04-01 14:18:59

Pattern in https://0x0.st/XzLv.txt hasn't changed and is different from the ones where gnome just crashes immediately.
GDM is btw. still (again) running on wayland?

@yurus, do you have

Window manager error: Another compositing manager is already running on screen 0 on display “:0”.

in your journal?

yurus · 2024-04-01 14:25:55

seth wrote:

Pattern in https://0x0.st/XzLv.txt hasn't changed and is different from the ones where gnome just crashes immediately.
GDM is btw. still (again) running on wayland?
@yurus, do you have
Window manager error: Another compositing manager is already running on screen 0 on display “:0”.
in your journal?

Hello @seth

Yes, the line shows

 Window manager error: Another compositing manager is already running on screen 0 on display “:1”.

seth · 2024-04-01 14:43:15

And because of ":1" you're also running GDM on X11 already

https://bbs.archlinux.org/viewtopic.php … 7#p2161627
See whether you can get an interactive shell and successfully run stuff from there this way.

werefkin · 2024-04-01 14:53:13

seth wrote:

GDM is btw. still (again) running on wayland?

yes, I reverted it.

Created an issue in the git
https://gitlab.gnome.org/GNOME/mutter/-/issues/3410

apparently this might be related
https://gitlab.gnome.org/GNOME/mutter/- … uests/3590

yurus · 2024-04-01 14:59:31

seth wrote:

And because of ":1" you're also running GDM on X11 already
https://bbs.archlinux.org/viewtopic.php … 7#p2161627
See whether you can get an interactive shell and successfully run stuff from there this way.

One workaround that I do after Gnome crashes is to login into TTY3 and run:

sudo systemctl restart gdm

Maybe it's because of that?

loqs · 2024-04-01 15:03:50

werefkin wrote:

https://gitlab.gnome.org/GNOME/mutter/- … uests/3590

Need any help building mutter with that merge request applied?

seth · 2024-04-01 15:19:29

@yurus, you mean if you restart GDM you can start gnome no problem?
If you only boot the multi-user.target and get a cup of coffee and then start GDM, can you log in w/o issues?

You've an nvidia GPU as well? "nvidia-drm.modeset=1" in your initramfs?
I'm not saying the merge isn't related, but the driver resetting because one doesn't XSync twice a frame (ie. 120Hz) is a pretty far stretch…

Does it have any impact if you enable triple buffering?
/etc/X11/xorg.conf.d/20-nvidia.conf

Section "Device"                                                                                                                
    Identifier "GeForce"
    Driver  "nvidia"
    Option  "TripleBuffer"          "True"
EndSection

yurus · 2024-04-01 15:25:05

seth wrote:

@yurus, you mean if you restart GDM you can start gnome no problem?
If you only boot the multi-user.target and get a cup of coffee and then start GDM, can you log in w/o issues?
You've an nvidia GPU as well? "nvidia-drm.modeset=1" in your initramfs?
I'm not saying the merge isn't related, but the driver resetting because one doesn't XSync twice a frame (ie. 120Hz) is a pretty far stretch…
Does it have any impact if you enable triple buffering?
/etc/X11/xorg.conf.d/20-nvidia.conf
Section "Device"                                                                                                                
    Identifier "GeForce"
    Driver  "nvidia"
    Option  "TripleBuffer"          "True"
EndSection

I mean, if I login and open an app shortly after the whole shell crashes. Then to recover from that I have to login into TTY3, restart GDM, login and wait a minute to then start opening apps.

And again, if I login (the shell starts automatically for me, I didin't understood the "multi-user.target" that you are referring to) and wait a minute, I can open apps and work normally.

I do have "nvidia-drm.modeset=1" set but my /etc/X11/xorg.conf.d/20-nvidia.conf is empty.

seth · 2024-04-01 15:31:52

For the multi-user.target see the 2nd link below.
The workaround is otherwise necessary, you cannot just wait a minute during the 1st login?

/etc/X11/xorg.conf.d/20-nvidia.conf was a suggestion to enable triple buffering to detach the foreground and scanout buffers, though I don't really believe that flushing the X11 event queue tooslow™ can cause a driver reset (it might however trip gnome in other ways)

werefkin · 2024-04-01 15:35:07

loqs wrote:

werefkin wrote:
https://gitlab.gnome.org/GNOME/mutter/- … uests/3590
Need any help building mutter with that merge request applied?

100% ;D I have no experience with that
edit: i guess it shall be without this merge applied

Last edited by werefkin (2024-04-01 15:37:03)

yurus · 2024-04-01 15:44:39

seth wrote:

For the multi-user.target see the 2nd link below.
The workaround is otherwise necessary, you cannot just wait a minute during the 1st login?
/etc/X11/xorg.conf.d/20-nvidia.conf was a suggestion to enable triple buffering to detach the foreground and scanout buffers, though I don't really believe that flushing the X11 event queue tooslow™ can cause a driver reset (it might however trip gnome in other ways)

Yes, sure I can wait a minute for the first login as a workaround.

I see a lot of people with this issue since GNOME 46 but no one has found the root cause yet. I'm not a developer but this feels like a race condition?

How can I monitor the system process loading to check what's lagging behind that is causing this issue? If the lag time is consistent (which apparently it is) maybe we can easily see what is taking too long to load and that is essential to draw app windows on the screen.

seth · 2024-04-01 15:53:32

Do the unproblematic logins also have a "Window manager warning: META_CURRENT_TIME used to choose focus window" warning in the journal?

yurus · 2024-04-01 16:09:40

I'll check that

Last edited by yurus (2024-04-01 16:10:47)

yurus · 2024-04-01 16:17:09

I can consistently not crash opening an app after the following messages appear on the journal

Apr 01 13:15:28 yoshi systemd[1511]: Starting Virtual filesystem metadata service...
Apr 01 13:15:28 yoshi systemd[1511]: Started Virtual filesystem metadata service.

werefkin · 2024-04-01 16:23:53

seth wrote:

Do the unproblematic logins also have a "Window manager warning: META_CURRENT_TIME used to choose focus window" warning in the journal?

let me also check

seth · 2024-04-01 16:25:35

Apr 01 15:27:12 main-pc systemd-logind[568]: New session 3 of user werefkin.
Apr 01 15:27:13 main-pc gnome-shell[1389]: Running GNOME Shell (using mutter 46.0) as a X11 window and compositing manager
Apr 01 15:27:13 main-pc systemd[1211]: Starting Virtual filesystem metadata service...
Apr 01 15:27:13 main-pc systemd[1211]: Started Virtual filesystem metadata service.
Apr 01 15:27:29 main-pc gnome-shell[1389]: Running GNOME Shell (using mutter 46.0) as a X11 window and compositing manager
…

Starting Virtual filesystem metadata service happens 1s into the session and the internal restart happens 16s later.

@yurus,

Window manager warning: META_CURRENT_TIME used to choose focus window

That token: does it appear in your journal
a) when the session did then crash
b) when the session didn't crash

yurus · 2024-04-01 16:43:23

seth wrote:

Apr 01 15:27:12 main-pc systemd-logind[568]: New session 3 of user werefkin.
Apr 01 15:27:13 main-pc gnome-shell[1389]: Running GNOME Shell (using mutter 46.0) as a X11 window and compositing manager
Apr 01 15:27:13 main-pc systemd[1211]: Starting Virtual filesystem metadata service...
Apr 01 15:27:13 main-pc systemd[1211]: Started Virtual filesystem metadata service.
Apr 01 15:27:29 main-pc gnome-shell[1389]: Running GNOME Shell (using mutter 46.0) as a X11 window and compositing manager
…

Starting Virtual filesystem metadata service happens 1s into the session and the internal restart happens 16s later.

@yurus,

Window manager warning: META_CURRENT_TIME used to choose focus window

That token: does it appear in your journal
a) when the session did then crash
b) when the session didn't crash

Here are my journalctl files:

Crash: https://0x0.st/XzpA.txt
Not crashed: https://0x0.st/Xzpa.txt

werefkin · 2024-04-01 18:54:15

seth wrote:

Window manager warning: META_CURRENT_TIME used to choose focus window
That token: does it appear in your journal

Here is my journal when there is no crash (needed several attempts): https://0x0.st/XzV7.txt

META_CURRENT_TIME is missing

seth · 2024-04-01 20:18:46

Same for yurus
The question (for your upstream bug) is whether that's simply a symptom of

This looks like something is restarting gnome-shell via Meta.restart()

or hints at the cause for the restart.

werefkin · 2024-04-01 22:43:58

seth wrote:

Same for yurus
The question (for your upstream bug) is whether that's simply a symptom of
This looks like something is restarting gnome-shell via Meta.restart()
or hints at the cause for the restart.

in other crash journals that I posted a few messages below (with firefox autostart), https://0x0.st/XzLv.txt and another one https://0x0.st/Xzcj.txt do not contain META_CURRENT_TIME as well, other do

Last edited by werefkin (2024-04-01 22:53:28)

werefkin · 2024-04-01 22:52:56

yurus wrote:

I'm not a developer but this feels like a race condition?

I also have the same feeling that it is a race issue

I can consistently not crash opening an app after the following messages appear on the journal
Apr 01 13:15:28 yoshi systemd[1511]: Starting Virtual filesystem metadata service...
Apr 01 13:15:28 yoshi systemd[1511]: Started Virtual filesystem metadata service.

This is not the case for me, I can observe it in any journal.

Arch Linux

#26 2024-04-01 09:29:46

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

#27 2024-04-01 12:48:24

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

#28 2024-04-01 13:30:37

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

#29 2024-04-01 14:11:57

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

#30 2024-04-01 14:18:59

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

#31 2024-04-01 14:25:55

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

#32 2024-04-01 14:43:15

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

#33 2024-04-01 14:53:13

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

#34 2024-04-01 14:59:31

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

#35 2024-04-01 15:03:50

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

#36 2024-04-01 15:19:29

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

#37 2024-04-01 15:25:05

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

#38 2024-04-01 15:31:52

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

#39 2024-04-01 15:35:07

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

#40 2024-04-01 15:44:39

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

#41 2024-04-01 15:53:32

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

#42 2024-04-01 16:09:40

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

#43 2024-04-01 16:17:09

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

#44 2024-04-01 16:23:53

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

#45 2024-04-01 16:25:35

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

#46 2024-04-01 16:43:23

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

#47 2024-04-01 18:54:15

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

#48 2024-04-01 20:18:46

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

#49 2024-04-01 22:43:58

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

#50 2024-04-01 22:52:56

Re: [SOLVED] Gnome 46 on X.Org crashes shortly after logging in

Board footer