GNOME Bugzilla – Bug 749656
screen freezes when notification gets pushed to gnome
Last modified: 2015-10-11 23:15:32 UTC
Behavior: Notification comes in via a notification-enabled application like spotify/hipchat/empathy Screen freezes for 30-120 seconds. No keyboard or mouse input will do anything. Clock in panel seconds do not increment until freeze stops. Mouse cursor is movable (but not clickable), audio stream if any continues. Gnome session does not typically startup with this problem, but when it gets in this state it happens with all notification messages I see multiple thousand messages in journalctl at the point of freezing, which all say e.g.: May 20 15:21:40 bklaas gnome-session[2277]: (gnome-shell:2412): Clutter-CRITICAL **: clutter_text_get_text: assertion 'CLUTTER_IS_TEXT (self)' failed May 20 15:21:40 bklaas gnome-session[2277]: (gnome-shell:2412): Clutter-CRITICAL **: clutter_text_set_text: assertion 'CLUTTER_IS_TEXT (self)' failed Additionally I see about 10 of these messages, and they are the first 10 messages printed on the exact second of the freeze May 20 15:13:34 bklaas gnome-session[2277]: (gnome-shell:2412): St-CRITICAL **: st_widget_get_theme_node I was a regular user of gnome 3.14 which never had this issue I have seen this from the first day I started using 3.16, and it has happened every day I've used it on 3.16.
Do you use any extensions? If you do, does this stop happening if you disable them?
Yes, I use: Dash-to-Dock, Redmine issues, Open Weather, Media Player Indicator, and Task Bar. I've shut them all off and am currently trying to reproduce (even before shutting them off, to reproduce the bug the gnome session would need to run for a while before the fail state would happen, after which the bug is 100% repeatable until reboot). I will update the bug with information as I get it.
The bug is reproducible with all extensions turned off.
I have been experiencing the same issue for some weeks. I talked with Florian, but couldn't figure it out. Looking at the code, there is no sync IO or something that could cause it, so I guess is a graphical issue, but it's strange that I only experience it with the notifications. Do you have some insight Rui?
Can you ssh in from another computer, run "gdb attach -p $(pidof gnome-shell)", and get a backtrace?
fwiw, i see this bug fairly regularly, but never when I'm trying to reproduce it.
I think it might be a dbus timeout since it appears to freeze for at least 20 seconds when it happens
I concur that freezes are a minimum of 20 seconds or so, on up to 1-2 minutes. I experience the problem on a MacBookPro running Arch Linux with up-to-date Gnome 3.16 and 4.0 Kernel. I do not experience the problem on a System76 GazellePro running Arch Linux with up-to-date Gnome 3.16 and 4.0 kernel. Both machines' Gnome environment configured more or less identically with the same extensions and the same tweaks and the same set of applications. On the macbook, I can reproduce with all extensions turned off. Macbook is not in my possession for long but I will try the gdb attach from an ssh session if I get an opportunity to do so.
This affects me too so I decided to make a account here. I wonder, does nobody use gnome? Or are just certain people affected? I don't know too much about how to find out why errors happen, and I don't have a second computer unfortunately. The bug can easily be reproduced (for me at least) by downloading a file in firefox, alt-tabbing to nautilus and waiting for the download to complete as this gives me a notification (which is very likely due to me using the "GNotifier" addon). I will help however I can, but as I said, I do not have another PC use for this, just my laptop.Btw I want to note that keyboard input does indeed do something: You can kill the X session with CTRL+ALT+BACKSPACE... I've installed KDE to be able to use my computer, however I'd love if this would get fixed (or a workaround be available until it does get fixed).
I haven't seen a bug, but as mentioned, it's probably due to the GNotifier addon. Does disabling that make it work?
Well, no. The addon just enables firefox to give a notification using the OS native way. I just mentioned it because it's easy to replicate like that. The same bug also happens however if I get a message on pidgin where someone said my name in IRC. Or a new email on geary (mail client). Pretty much anything that uses notifications. Now, I am _unsure_, but I think that it also happens when you get the message 'SOMEAPPLICATION is ready'.
I haven't seen any such screen freeze then. Is there anything in the journal?
I'm seeing exactly the same problem using Scudcloud (a QT based Slack client which wraps webkit). Whenever I hear notifications arrive, the whole of the shell freezes for about 10 seconds, then everything catches up and the notifications are displayed.
I'm seeing what sounds like the same issue on Arch Linux 64-bit with GNOME 3.16. I have Intel HD 3000 Graphics (Sandybridge). Removing all Shell extensions didn't help. I'm not using any custom themes (all GNOME defaults). I tried switching GDM to use Xorg instead of Wayland. I tried disabling anything related to graphics acceleration (vaapi and vdpau). Nothing helped. However, after switching off notifications a couple days ago I can no longer reproduce the issue. Symptoms: notifications from Firefox completing a download (using GNotifier extension), Transmission-Gtk completing a download, or GNOME Music starting play of an album would freeze the Shell for 30 seconds or so (and in case of GNOME Music sometimes even crash it). Mouse cursor would still be movable but otherwise the display would be fully frozen. Video playback appears frozen though audio keeps playing. Also music keeps playing. The virtual consoles are fully operable and show no symptoms of a freeze. It started happening at least 4 weeks ago and would have started not much further back. I think I remember having done a clutter or mutter upgrade just before this started happening. My upgrade logs from that period for these two: [2015-07-02 14:46] [ALPM] upgraded clutter-gst (3.0.6-2 -> 3.0.6-3) [2015-07-02 22:50] [ALPM] upgraded mutter (3.16.2-2 -> 3.16.3-1) [2015-07-17 09:10] [ALPM] upgraded clutter-gst (3.0.6-3 -> 3.0.6-4) [2015-07-17 09:10] [ALPM] upgraded clutter-gst2 (2.0.14-1 -> 2.0.16-1) [2015-07-19 09:14] [ALPM] upgraded clutter-gst (3.0.6-4 -> 3.0.8-1) I suspect clutter 3.0.8 from the date. Unfortunately I don't have the older versions of these packages on my system to try a downgrade to confirm. Anybody handy with bisecting the code? When it happened I investigated from a virtual console. journal shows nothing happening. I don't know how to get gnome-shell to log more. htop shows gnome-shell process using 100% on 1 CPU core.
That's extremely bizarre. Can you reproduce it with anything but GNOME Music?
Yes, it happens with "download complete" notifications from Firefox and Transmission as well. I had suspected at one point GNOME Music to be the cause, seeing as it would at times also crash. Did a reboot and didn't launch GNOME Music; the freeze still happened from Firefox or Transmission notifications. Those are the examples that stand out most, as these are the applications with notifications that I used most in the past month. But also File Roller notifications would cause a freeze IIRC. I can't think of other applications I used that have notifications. Often after a reboot or GDM restart the freeze wouldn't happen immediately. But after some short time thefreeze would start happening and then happen consistently for each notification.
I did some more testing: - I enabled notifications and in the same session the freeze immediately starts happening for notifications (30 second freeze, then notification pops up as the Shell unfreezes) - I toggled GNotifier in Firefox and indeed disabling it stops the freezes and enabling it starts the freezes again (downloading the same file; I did the test with both enabled and disabled a couple of times). However, as the freezes also happen for other applications giving notifications I don't think GNotifier is the cause--other than that it enables using system notifications, which causes freezes. I only have one computer here. What can I do to help diagnose this issue? journal isn't showing anything relevant.
Today the freezes are happening again for me. Less often, but still happening despite disabled notifications. I can't be sure it's not caused by something else. I'm all out of clues on how to diagnose my issue, but probably there is more at play for me than OP's issue with notifications :(
It appears that the freezing doesn't just happen with notifications from Qt apps as I thought! I'm getting freezing from Epiphany webapp notifications too, and also occasionally from the terminal notifications. This is making GNOME unbearable to use - it's freezing every few minutes. I couldn't see anything in the journal that would explain this. Using Fedora 22 on Intel graphics.
We really need to get both C and Javascript backtraces for the frozen state. If you see the hang frequently, can you: Prep: log in to a virtual console type without hitting return yet: sudo gdb -p `pgrep -u $USER ^gnome-shell$` Time critical: When the hang occurs, switch to the VC and hit return Not time critical - inside gdb: set logging file gdb-gnome-shell.text thread apply all bt call gjs_dumpstack() quit Then switch back to the gnome-shell session. Attach the file gdb-gnome-shell.txt here and also extract from the systemd log (journalctl) the JS stack that was logged when you called gjs_dumpstack(). Thanks!
i see this problem regulary with hexchat notifications, but both times I sat down to try to reproduce and look at the problem I couldn't make it happen. I think it may only happen after gnome-shell has been running for a while? or maybe it only happens for a run of notifications and then stop happening again. i'm really not sure, but I'll keep a closer eye on it and see if I can figure it out.
*** Bug 750346 has been marked as a duplicate of this bug. ***
This was possibly fixed in bug 755425.
I did a scratch fedora 22 build with that patch here: http://koji.fedoraproject.org/koji/taskinfo?taskID=11308501 will try it for a few days and report back.
Could this have been related to bug #752045 as well?
not sure about bug 752045, but i haven't had a freeze up with xchat in a few days, so i'm going to dupe this to 755425 *** This bug has been marked as a duplicate of bug 755425 ***
Using an up-to-date fedora 22, I have been having this issue for a while as well, mostly with Gajim notifications and Firefox download notifications. Glad to hear that it was probably solved with bug 755425 :). Do we know when this will be integrated in upstream Gnome? I'm currently using 3.16.3.
(In reply to Gwendal from comment #27) > Using an up-to-date fedora 22, I have been having this issue for a while as > well, mostly with Gajim notifications and Firefox download notifications. > > Glad to hear that it was probably solved with bug 755425 :). Do we know when > this will be integrated in upstream Gnome? I'm currently using 3.16.3. It's fixed in 3.18.0 and it looks like a fairly safe commit, so I backported it so it will be fixed in 3.16.4 if there is ever a 3.16.4 release. There's enough fixes accumulated on that branch now to make such a release worthwhile....
Great, thanks for the information! I'll probably fedup to fedora 23 rapidly then.
This is great news, and indeed in 3.18 I have not seen this problem. I want to thank all of you for debugging this issue and fixing it. It does not look like it was an easy problem to debug!
(In reply to Sri Ramkrishna from comment #30) > This is great news, and indeed in 3.18 I have not seen this problem. That's luck - the patch landed shortly after 3.18.0, so it will only be in the 3.18.1 release that's due next week :-)
Er, yeah, oops!
Well, I've been using wayland, not sure if that is a factor. But cool all the same. :)