Bug 957363

I had a similar issue. It was caused by an extension that failed to set the "text" attribute on a label it created. The fix was to simply place an empty string as the initial value for that attribute.

You should check if disabling any of your extensions fixes the problem.

Possibly either gnome-shell or clutter could be made more resistant against nulls where strings are expected, so that badly behaving applications do not spam users' logs. At the very least, it would be useful if the log messages contained the name of the offending extension, so that bugs can be filed against the correct component.

Same issue here on F19 final. Disabling all extensions fixed the problem, though enabling them again didn't reproduce this bug. Don't really know what happened.

Ok, I have to correct myself. What fixed it yesterday was NOT disabling all extensions but logging off and on again (as does restarting gnome shell). This bug is not caused by any gnome shell extensions: I manually disabled each of them and still keep getting those errors. Only restarting gnome-shell works around this bug.
I haven't found a way to reproduce but it looks like gnome shell needs to be running >2 hours to make this bug happen.

I can confirm this is happening to me as well. It makes the entire screen and all apps freeze for a few seconds every few minutes.

Doing an Alt-F2 + r clears it up and stops the flood of messages in my /var/log/messages and I don't know what brings the problem back but it does return within the same session (no logouts, no reboots).

Same issue here on F19 with all updates as of 12/07. Constant errors logged by systemd-journald:

/etc/gdm/Xsession[1455]: (gnome-shell:1727): Clutter-CRITICAL **: clutter_text_set_text: assertion `CLUTTER_IS_TEXT (self)' failed

Every 5-10 seconds gnome-shell uses 50-100% of CPU and everything freezes.

Please make it stop...

Same log-spamming issue here:  gnome-shell-3.8.3-3.fc19.x86_64

Idle gnome-shell CPU usage doesn't quite rise to 20%, more like 5% and below.

I see two variants of the logspam message:

Jul 12 15:21:32 gaspode /etc/gdm/Xsession[5092]: (gnome-shell:5209): Clutter-CRITICAL **: clutter_text_get_editable: assertion `CLUTTER_IS_TEXT (self)' failed

Jul 12 15:21:42 gaspode /etc/gdm/Xsession[5092]: (gnome-shell:5209): Clutter-CRITICAL **: clutter_text_get_text: assertion `CLUTTER_IS_TEXT (self)' failed

Actions that trigger it so far:

- Lock/unlock desktop.  Doesn't seem to matter whether lockscreen notifications are enabled or not in privacy settings.

- Change focus between windows that are each maximized on different monitors.  This one doesn't always cause the cascade of log messages, and I've only been able to reproduce it with focus-follows-mouse in the tweak tool, and not with the (default) of focus-follows-click.

Verified, a reset of the shell stops the issue for me.  A screen lock/unlock cycle starts it up again.

Fedora 19 all patches current:

3.9.9-301.fc19.x86_64 #1 SMP Thu Jul 4 15:10:36 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Jul 15 22:04:15 neptune /etc/gdm/Xsession[6145]: (gnome-shell:6409): Clutter-CRITICAL **: clutter_text_get_editable: assertion `CLUTTER_IS_TEXT (self)' failed
Jul 15 22:04:15 neptune /etc/gdm/Xsession[6145]: (gnome-shell:6409): Clutter-CRITICAL **: clutter_text_get_text: assertion `CLUTTER_IS_TEXT (self)' failed
Jul 15 22:04:15 neptune /etc/gdm/Xsession[6145]: (gnome-shell:6409): Clutter-CRITICAL **: clutter_text_set_text: assertion `CLUTTER_IS_TEXT (self)' failed


gnome-shell-extension-common-3.8.3-2.fc19.noarch
gnome-shell-3.8.3-3.fc19.x86_64
gnome-shell-extension-user-theme-3.8.3-2.fc19.noarch

Thanks for this hint. I found the extension triggering this bug by try-and-error:
sensors:
https://extensions.gnome.org/extension/82/cpu-temperature-indicator/
https://github.com/xtranophilist/gnome-shell-extension-sensors

This is also a known bug to sensors extension: https://github.com/xtranophilist/gnome-shell-extension-sensors/issues/83

As a workaround I suggest disabling the sensors extension.

(In reply to Christian Stadelmann from comment #8)
> Thanks for this hint. I found the extension triggering this bug by
> try-and-error:
> sensors:
> https://extensions.gnome.org/extension/82/cpu-temperature-indicator/
> https://github.com/xtranophilist/gnome-shell-extension-sensors
> 
> This is also a known bug to sensors extension:
> https://github.com/xtranophilist/gnome-shell-extension-sensors/issues/83
> 
> As a workaround I suggest disabling the sensors extension.

Yes the extension does cause excessive logging and higher cpu usage of gnome-shell, but even with the extension now uninstalled the desktop still becomes laggy and unresponsive after a period of time, again with high cpu usage for gnome-shell process. The only temporary fix is alt-F2 and "r" until the next time about 20-30 minutes later.

@Pat Gardner:
Do you still see those messages in /var/log/messages ?
If yes: do you have other extensions installed that may trigger this bug?
If no: Seems like you ran into a different but potentially similar bug. You should report it separately.

Should messages like these really end up in /var/log/messages?
What is .xsession-errors supposed to be in Fedora 19?

I am plagued by the same error on Fedora 19.
I get a dozen of these errors every 10 seconds..

I toggled each addon using gnome-tweak-tool and disabling them never helped.

(In reply to Turgut Kalfaoglu from comment #12)
> I toggled each addon using gnome-tweak-tool and disabling them never helped.

I think one needs to disable sensors extension and then restart GNOME Shell (or perhaps the whole GNOME session).

Correct -- thank you. After disabling sensors applet and restarting gnome, the errors have stopped..

Comment 11 has not really been answered yet.
I have no sensors extension, just a system-monitor which has been configured correctly.
AFAIK thiese messages do not belong in /var/log/messages but in a file ~/.xsession-errors or whatever it was called.
It appears that this file has been obsolted for no reason.
This is a very unfortunate action and has to be reversed.

See comment 15.

@udo: I think you should report a separate bug for that.

The bug occurs even when no gnome-shell extension installed

I want to take back my words back of the above comment 18:
After NOT loading the Extensions 'Sensors', 'Weather' and 'System-monitor' NO 'Clutter-CRITICAL' messages appear anymore in the messages log file after restarting the gnome-shell.

Disabling the sensors extension and restarting (kill -HUP) the gnome-shell stopped the flood of messages on my system as well.
But on my system I noticed higher memory consumption more than higher CPU consumption.

I see the same issue with:
kernel-3.10.7-200.fc19.x86_64
gnome-shell-3.8.4-2.fc19.x86_64

It doesn't matter if I have extensions enabled or not.

(In reply to Miroslav Vadkerti from comment #21)
> It doesn't matter if I have extensions enabled or not.

One needs to restart GNOME Shell before it takes effect.

I get the same issue : after a long period of use (over 2 hours) I get those messages in the log file :
Sep 26 14:46:44 localhost gnome-session[1491]: (gnome-shell:1771): Clutter-CRITICAL **: clutter_text_get_editable: assertion `CLUTTER_IS_TEXT (self)' failed
Sep 26 14:46:44 localhost gnome-session[1491]: (gnome-shell:1771): Clutter-CRITICAL **: clutter_text_get_text: assertion `CLUTTER_IS_TEXT (self)' failed
Sep 26 14:46:44 localhost gnome-session[1491]: (gnome-shell:1771): Clutter-CRITICAL **: clutter_text_set_text: assertion `CLUTTER_IS_TEXT (self)' failed

There are around 10 messages every 2 seconds. Sometimes, Gnome hangs for a few seconds then comes back, it is really annoying.

After reading all the previous comments, I managed to "fix" it when it happens using Alt-F2 and "r", but it comes back after another couple of hours and after each reboot.

Is there is proper fix I could apply ? Long time ?

As a workaround comment #20 (disabling the Sensors extension) stopped the flood for me.

Today, I fixed yet another instance of this issue in the transmission-daemon-indicator Gnome Shell extension.

The root cause was that upon init, an object was created that connected a signal from a global object to itself, but neglected to disconnect that signal when it was destroyed upon disable. This caused the object to stay alive, but somehow two of its instance variables (Labels) were nulled, causing the errors.

if someone wants to debug this issue with an extension where the problem is easily reproducible, use the revision prior to this: https://github.com/Chousuke/gnome-shell-extension-transmission-daemon/compare/clutter-fix

in particular, without the "destroy" connection, two assignments occur in updateOptions which trigger the spam after the extension has been disabled and re-enabled once. The first is "this._status.text = stats_text"; and the second is via this.menu.controls.setInfo(info_text);

I see this as well, using the Cinnamon desktop.  So far as I can tell, I don't have any extensions running or enabled.  This is incredibly annoying.  My /var/log/messages got to well over 4 GB in a single week.  Well over 1000 times its usual size.  Yes, 99.99% of /var/log/messages for that week is the three lines:

Dec 11 09:21:22 localhost /etc/gdm/Xsession[1746]: (cinnamon:1977): Clutter-CRITICAL **: clutter_text_get_editable: assertion `CLUTTER_IS_TEXT (self)' failed
Dec 11 09:21:22 localhost /etc/gdm/Xsession[1746]: (cinnamon:1977): Clutter-CRITICAL **: clutter_text_get_text: assertion `CLUTTER_IS_TEXT (self)' failed
Dec 11 09:21:22 localhost /etc/gdm/Xsession[1746]: (cinnamon:1977): Clutter-CRITICAL **: clutter_text_set_text: assertion `CLUTTER_IS_TEXT (self)' failed

Just adding a 'me too' here. My experience is the same as comment #9. Additionally I noticed that this behaviour (ie: excessive logging and higher cpu usage of gnome-shell) is also triggered on a resume after a system suspend.

I come together with you all.
Although this is clearly a problem to address at GNOME-project...

Hello Red Hat maintainers! Please, mark the issue as "confirmed" and help us all bring more impact at Gnome-guys.

The lack of an API for gnome-extensions is a MAJOR mistake in the whole project!

Unfortunately Gnome project-managers can't prove competence to admin their project.

Help!

Please move to Fedora 20.  I now have 20 GB of /var/log/messages.
It's taking over the drive. The journal is probably now a monster.

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

(gnome-shell:3847): Clutter-CRITICAL **: clutter_text_get_editable: assertion 'CLUTTER_IS_TEXT (self)' failed
(gnome-shell:3847): Clutter-CRITICAL **: clutter_text_get_text: assertion 'CLUTTER_IS_TEXT (self)' failed
(gnome-shell:3847): Clutter-CRITICAL **: clutter_text_set_text: assertion 'CLUTTER_IS_TEXT (self)' failed

This happens to me about every 10 minutes.
gnome-shell-3.8.4-45

(In reply to Morris from comment #33)
> This happens to me about every 10 minutes.
> gnome-shell-3.8.4-45

I have seen that too. Does not belong in /var/log/messages but other people have decided otherwise without explaining this wisdom.

This stuff belongs in a log like ~/.xsession-errors or very similar.

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.