Open andrejpodzimek opened 3 years ago
Ouch, I'll try to see if I find anything but have never header of anything like this before, nor experienced this
Same issue on Fedora 34 Beta. I know GPaste is not yet supported for GNOME 40, but just giving you a heads up. I had to do a Dconf reset to trace it down. The errors were always related to gjs.
<offtopic>
The way Gnome extensions work seems troublesome to start with, because a single failing extension can crash the whole session (at least on Wayland). There doesn’t seem to be an easy way to debug this. (One would expect that certain 1970s inventions like separate processes / address spaces could be leveraged by gnome-session
to mitigate the problem.) Now there is (also) another extension that crashes the whole session, but, unlike GPaste, it won’t do so 100% reproducibly. It only happens once in ~5 screen lock activations, which makes the issue ultra-confusing and hard to track.</offtopic>
That said, in retrospect I would speculate that the spurious session crashes I had been observing for months (mentioned in my report above) had been in fact caused by this extension, whereas the 100% reproducible GPaste-related crashes are a new thing that started recently (~2 weeks ago).
With both extensions deactivated, locking and unlocking 100 times did not yield any session crashes. (Which is not a good workaround, because GPaste is useful and having no way to see Qt/KDE applications’ tray icons is not exactly great.)
@andrejpodzimek would you be available for some discord or zoom call to debug this since you reliably can trigger this ?
@andrejpodzimek would you be available for some discord or zoom call to debug this since you reliably can trigger this ?
@Keruspe Sure, I can do Zoom, Discord, Signal or Hangouts. (I’d have to connect from my phone to be able to crash the desktop session a couple of times, but that’s doable.)
BTW, here’s my latest observation:
So for some reason there’s only an issue when GPaste is enabled upon login and enabled at the moment of screen locker activation. Enabling it later during the session doesn’t provoke the crashes and disabling it stops them.
Which gjs mutter and gnome-shell versions are you running ?
gjs
2:1.68.0-2
mutter
3.38.4-2
gnome-shell
1:3.38.4-1
(The thing after the last dash is an Arch package version suffix (basically build config version) and the thing before the :
(when present) is Arch’s epoch (an optional (and last-resort) version downgrade mechanism / version comparison glitch workaround).)
Will see if I have the same versions locally and try to reproduce with those if not.
Which timezone are you in?
I'm in CEST.
BTW, there’s mutter
40.0-3
and gnome-shell
1:40.0-1
in the staging repo. Should I try that?
Can you try downgrading gjs to 1.66 if faisible?
I see one of the changelog entries for 1.68 being "session crashes in gjs on unlocking (sometimes)" so there might still be fishy things in that area I guess?
GPaste currently won't work on gnome 40 (I think? If I'm wrong that'd be awesome though) until the gtk4 port is over
Ah, OK, in that case the .*40.*
switch could be quite an ordeal anyway, until (and unless) it makes it from Staging to Extra in Arch, including all deps.
I’m trying to build gjs
1.66
from AUR, but I’m getting these build errors:
53/60 gjs:JS / Gtk4 ERROR 0.49s killed by signal 11 SIGSEGV
54/60 gjs:JS / Introspection ERROR 0.90s killed by signal 11 SIGSEGV
55/60 gjs:JS / GObjectDestructionAccess ERROR 0.84s killed by signal 11 SIGSEGV
56/60 gjs:JS / Gtk3 ERROR 0.85s killed by signal 11 SIGSEGV
57/60 gjs:JS / Cairo ERROR 0.87s killed by signal 11 SIGSEGV
58/60 gjs:JS / LegacyGtk ERROR 0.86s killed by signal 11 SIGSEGV
What I see in audit logs around that time:
Apr 02 20:57:18 <hostname> audit[1782880]: ANOM_ABEND auid=1984 uid=1984 gid=1984 ses=5 pid=1782880 comm="gjs-console" exe="/home/andrej/inst/gjs/src/build/gjs-console" sig=5 res=1
Apr 02 20:57:18 <hostname> audit[1782916]: ANOM_ABEND auid=1984 uid=1984 gid=1984 ses=5 pid=1782916 comm="gjs-console" exe="/home/andrej/inst/gjs/src/build/gjs-console" sig=5 res=1
Apr 02 20:57:18 <hostname> audit[1781857]: ANOM_ABEND auid=1984 uid=1984 gid=1984 ses=5 pid=1781857 comm="minijasmine" exe="/home/andrej/inst/gjs/src/build/installed-tests/js/minijasmine" sig=11 res=1
Apr 02 20:57:18 <hostname> audit[1782157]: ANOM_ABEND auid=1984 uid=1984 gid=1984 ses=5 pid=1782157 comm="minijasmine" exe="/home/andrej/inst/gjs/src/build/installed-tests/js/minijasmine" sig=11 res=1
Apr 02 20:57:18 <hostname> audit[1782138]: ANOM_ABEND auid=1984 uid=1984 gid=1984 ses=5 pid=1782138 comm="minijasmine" exe="/home/andrej/inst/gjs/src/build/installed-tests/js/minijasmine" sig=11 res=1
Apr 02 20:57:18 <hostname> audit[1782169]: ANOM_ABEND auid=1984 uid=1984 gid=1984 ses=5 pid=1782169 comm="minijasmine" exe="/home/andrej/inst/gjs/src/build/installed-tests/js/minijasmine" sig=11 res=1
Apr 02 20:57:18 <hostname> audit[1782134]: ANOM_ABEND auid=1984 uid=1984 gid=1984 ses=5 pid=1782134 comm="minijasmine" exe="/home/andrej/inst/gjs/src/build/installed-tests/js/minijasmine" sig=11 res=1
Apr 02 20:57:18 <hostname> audit[1783015]: ANOM_ABEND auid=1984 uid=1984 gid=1984 ses=5 pid=1783015 comm="gjs-console" exe="/home/andrej/inst/gjs/src/build/gjs-console" sig=5 res=1
There seem to be lots of issues with gjs 1.68.0, and this MR shoul fix those IIUC: https://gitlab.gnome.org/GNOME/gjs/-/merge_requests/593
Actually, maybe it’s a chicken-and-egg problem where the test()
for gjs
is using the (potentially broken) 1.68
while building the package. It which case the best bet is probably to wait for the MR.
Had similiar issue on Fedora 33 (latest updates) up until 5 days ago. Last round of updates solved the crash issue.
I cannot reproduce with gnome 40 here (upgraded both gjs and gnome-shell at the same time, might be related)
I can no longer reproduce this problem in Gnome 40 with Fedora 34.
This is still 100% reproducible on my system after the upgrade to gnome-shell
40. Locking the screen(s) with gpaste
causes a crash. Without gpaste
(i.e., after deactivation of gpaste
in gnome-extensions-app
), locking works normally.
I can no longer reproduce this problem in Gnome 40 with Fedora 34.
How did you install gpaste in fedora34 ?
I can no longer reproduce this problem in Gnome 40 with Fedora 34.
How did you install gpaste in fedora34 ?
You have to disable the extension version checks in Dconf. It's not recommended for obvious reasons.
Can u send me some more detail via pm at (luca dot botti at gmail dot com)
Thanks
Il giorno mar 13 apr 2021 alle ore 13:06 Lateef Alabi-Oki < @.***> ha scritto:
I can no longer reproduce this problem in Gnome 40 with Fedora 34.
How did you install gpaste in fedora34 ?
You have to disable the extension version checks in Dconf. It's not recommended for obvious reasons.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Keruspe/GPaste/issues/346#issuecomment-818650043, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACT2MOGTE7Q73RIELTOQJ3TIQQSPANCNFSM42DVVBWA .
This is still 100% reproducible on my system after the upgrade to gnome-shell 40. Locking the screen(s) with gpaste causes a crash. Without gpaste (i.e., after deactivation of gpaste in gnome-extensions-app), locking works normally.
Alright, now I see that there are multiple extensions capable of causing session crashes in Gnome 40. Also, it looks like the error messages are now different or hidden somehow; it’s likely not the same crash as before.
That said, I no longer think that GPaste is to blame. GPaste may well be more of a victim in this case than anything else. Problems in Gnome just happen to surface when GPaste is used.
<offtopic>
\
One would think that the very reason why desktop environments migrated substantial amounts of code from C/C++ to dynamic languages (especially for extensions) and from monoliths to separate processes was to prevent exactly this from happening: One problem with one extension (regardless its root cause) should not take down the whole session.
Apparently, this^^^ basic principle doesn’t hold in Gnome. The previous version didn’t work right, the current one (40) doesn’t work any better. Gnome is broken, as far as reliability is concerned. If only KDE supported Wayland and MST 5k monitors a bit better — I would be back to KDE in no time.\
</offtopic>
[...]
<offtopic>
One would think that the very reason why desktop environments migrated substantial amounts of code from C/C++ to dynamic languages (especially for extensions) and from monoliths to separate processes was to prevent exactly this from happening: One problem with one extension (regardless its root cause) should not take down the whole session.Apparently, this^^^ basic principle doesn’t hold in Gnome. The previous version didn’t work right, the current one (40) doesn’t work any better. Gnome is broken, as far as reliability is concerned. If only KDE supported Wayland and MST 5k monitors a bit better — I would be back to KDE in no time.
</offtopic>
Isn't Gnome 40 planned to fix the issues with extensions by officially supporting them (in place of current no man's land Gnome thinking...) ?
Isn't Gnome 40 planned to fix the issues with extensions by officially supporting them (in place of current no man's land Gnome thinking...) ?
I thought so, but now that I’m running version 40, stability is worse than ever. The only difference is that there’s gnome-extensions-app
instead of gnome-tweaks
to configure extensions.
Whether extensions are supported or not, if one single extension can kill the whole session, then the entire software ecosystem is unsustainable. By contrast, in KDE,
This^^^ is why I find the impact of failing extensions on Gnome so surprising.
luca dot botti at gmail dot com
Sent you an email.
Hey, so GPaste doesn't crash for me when I lock, but I am not able to lock my screen when "Track Changes" is switched on. I have to manually switch it off each time I want to lock the screen. If I attempt to lock the screen with "Track Changes" on, the screen briefly locks and unlocks itself without the use of a password. Not sure if this is related, or if I should make this it's own issue.
I am running Manjaro shipped with Gnome.
Huh, this makes no sense at all !
The only thing "Track Changes" does is enable or disable the fact that the daemon adds stuff to the history when it receives clipboard events.
The only interaction we have with the screensaver is that we listen to events of screensaver activation/deactivation to clear the clipboard when the screensaver is activated and restore it once deactivated
Since I deactivated the option sync deamon with extension
my session doesn't crash anymore.
But sometimes my history is reset and only the last item is stored in it until I restart the daemon.
I am also running Manjaro shipped with Gnome 40.
I had been suspecting “Dash to panel”, based on a few bug reports from the past, but a long trial-and-error session full of crashes,
gnome-tweaks
and one-by-one extension (de)activation eventually pointed at GPaste, beyond any doubt.My hardware configuration may be somewhat unusual, but perhaps not unusual enough to warrant such annoying crashes. Crashes are 100% reproducible (since ~1 week ago; they had not been frequent enough to force me to investigate before that time, which is not to say they had not been happening). The whole Gnome session goes out of the window instantly, both upon explicit screen locking and upon automatic locking after a timeout. Everything in the session is lost and GDM chimes in, like “ugh, would you like to log in, maybe?” — what a joy.
The system is an ASRock X570 Creator with AMD Ryzen 3950X and an AMD Radeon Pro W5700. There are two 5k monitors (5120×2880, HP Z29q) with two DisplayPorts each, i.e., one big desktop that spans 10240×2880 and 4 monitors altogether (2 tiles per physical monitor). The distro is ArchLinux with kernel
5.11.10
,gnome-session
3.38.0+14+g87d92fec
andgpaste
3.38.6
.GPaste deactivation fixes the problem and the screenlocker in Gnome works normally again, without killing the session.