search

Keruspe / GPaste

Clipboard management system
BSD 2-Clause "Simplified" License
773 stars 55 forks source link

GPaste crashes Gnome whenever the screen is locked #346

Open andrejpodzimek opened 3 years ago

andrejpodzimek commented 3 years ago

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.

gnome-shell[957853]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.

gnome-shell[957853]: Attempting to run a JS callback during garbage collection. This is most likely caused by destroying a Clutter actor or GTK widget with ::destroy signal connected, or using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked.

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 and gpaste 3.38.6.

GPaste deactivation fixes the problem and the screenlocker in Gnome works normally again, without killing the session.

Keruspe commented 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

mystilleef commented 3 years ago

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.

andrejpodzimek commented 3 years ago

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

Keruspe commented 3 years ago

@andrejpodzimek would you be available for some discord or zoom call to debug this since you reliably can trigger this ?

andrejpodzimek commented 3 years ago

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

Keruspe commented 3 years ago

Which gjs mutter and gnome-shell versions are you running ?

andrejpodzimek commented 3 years ago

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

Keruspe commented 3 years ago

Will see if I have the same versions locally and try to reproduce with those if not.

Which timezone are you in?

andrejpodzimek commented 3 years ago

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?

Keruspe commented 3 years ago

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

andrejpodzimek commented 3 years ago

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
Keruspe commented 3 years ago

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

andrejpodzimek commented 3 years ago

Correction: Those errors are from check(), not from build(). So I guess I could get past them in case of dire need, but it doesn’t make me hopeful that the resulting package would work well.

andrejpodzimek commented 3 years ago

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.

lucabotti commented 3 years ago

Had similiar issue on Fedora 33 (latest updates) up until 5 days ago. Last round of updates solved the crash issue.

Keruspe commented 3 years ago

I cannot reproduce with gnome 40 here (upgraded both gjs and gnome-shell at the same time, might be related)

mystilleef commented 3 years ago

I can no longer reproduce this problem in Gnome 40 with Fedora 34.

andrejpodzimek commented 3 years ago

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.

lucabotti commented 3 years ago

I can no longer reproduce this problem in Gnome 40 with Fedora 34.

How did you install gpaste in fedora34 ?

mystilleef commented 3 years ago

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.

lucabotti commented 3 years ago

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 .

andrejpodzimek commented 3 years ago

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>

lucabotti commented 3 years ago

[...]

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

andrejpodzimek commented 3 years ago

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.

mystilleef commented 3 years ago

luca dot botti at gmail dot com

Sent you an email.

zachspar commented 3 years ago

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.

Keruspe commented 3 years ago

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

adminelix commented 3 years ago

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.