Bug 1350303

I am able to reproduce this on Gentoo gnome-shell-3.18.5

Thus far I've been able to reproduce on three separate systems, albeit unreliably.  Initial login/unlock attempts are consistently broken, after that it disappears randomly during package installs -- although nothing specific that I can tell -- or on the 2nd or 3rd attempt at reinstalling the whole system.  I still have no idea what's causing it, though.  As soon as I have time, I'll try my usual install procedure on a VM that doesn't have a preexisting copy of my home directory and see if I can narrow it down further.

See if you can get somewhere with `librsvg`. Got this tip from arch linux forum.

Similar situation is happening in vm environment on Fedora25. I cannot login from gdm login screen, if I use autologin and I am prompted for administrator password at any point, session is frozen. 

VM HW: (output of lspci -nn)
00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC [Natoma] [8086:1237] (rev 02)
00:01.0 ISA bridge [0601]: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] [8086:7000]
00:01.1 IDE interface [0101]: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] [8086:7010]
00:01.2 USB controller [0c03]: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] [8086:7020] (rev 01)
00:01.3 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI [8086:7113] (rev 03)
00:02.0 VGA compatible controller [0300]: Red Hat, Inc. QXL paravirtual graphic card [1b36:0100] (rev 03)
00:03.0 Ethernet controller [0200]: Red Hat, Inc Virtio network device [1af4:1000]
00:04.0 SCSI storage controller [0100]: Red Hat, Inc Virtio block device [1af4:1001]
00:05.0 RAM memory [0500]: Red Hat, Inc Virtio memory balloon [1af4:1002]

Error log (appered when user tries to authenticate)
Nov 21 09:18:31 qe-dell-ovs5-vm-12.dqe.lab.eng.bos.redhat.com gnome-shell[32322]: JS ERROR: Error: can't convert this._frame to an integer
                                                                                  Animation<._showFrame@resource:///org/gnome/shell/ui/animation.js:59
                                                                                  wrapper@resource:///org/gnome/gjs/modules/lang.js:178
                                                                                  Animation<.play@resource:///org/gnome/shell/ui/animation.js:34
                                                                                  wrapper@resource:///org/gnome/gjs/modules/lang.js:178
                                                                                  AuthenticationDialog<._setWorking@resource:///org/gnome/shell/ui/components/polkitAgent.js:195
                                                                                  wrapper@resource:///org/gnome/gjs/modules/lang.js:178
                                                                                  AuthenticationDialog<._updateSensitivity@resource:///org/gnome/shell/ui/components/polkitAgent.js:262
                                                                                  wrapper@resource:///org/gnome/gjs/modules/lang.js:178
                                                                                  AuthenticationDialog<._onEntryActivate@resource:///org/gnome/shell/ui/components/polkitAgent.js:267
                                                                                  wrapper@resource:///org/gnome/gjs/modules/lang.js:178

Can confirm that this still affects Fedora 25, and worse than before: whatever randomly cleared it up after package installs or full OS installs in 24 no longer does.  Upstream fix looks reasonable -- assuming missing animation frames are the underlying problem -- but there's still no indication of what it's trying and failing to load in the current build, or why logins work on the second attempt.

A bit more digging reveals that it's trying to load resource:///org/gnome/shell/theme/process-working.svg, which is in fact contained in /usr/share/gnome-shell/gnome-shell-theme.gresource, which is mapped into the process in question:

gnome-she 1494  rob  mem       REG              253,1   437767 3019285 /usr/share/gnome-shell/gnome-shell-theme.gresource

I'm rapidly running out of ideas about what it's failing to accomplish and why...

Found it.  gdk-pixbuf2 thinks it can't load SVG images, due to a stale /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders.cache.

The gdk-pixbuf2 and gdk-pixbuf2-modules packages are getting pulled in earlier in these installs than librsvg2, and the latter is not causing the file triggers from gdk-pixbuf2 to run, thus the stale cache.  Forcibly reinstalling gdk-pixbuf2 afterward corrects this.

Here's an example, starting from a new install with gdk-pixbuf2 installed but no librsvg2:

╶➤ rpm -qa |grep -e pixbuf -e svg |sort
gdk-pixbuf2-2.36.0-1.fc25.x86_64
gdk-pixbuf2-modules-2.36.0-1.fc25.x86_64

╶➤ ls -l /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders.cache
-rw-r--r--. 1 root root 2866 Nov 28 20:03 /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders.cache

╶➤ sudo dnf -y install librsvg2

╶➤ rpm -qa |grep -e pixbuf -e svg |sort
gdk-pixbuf2-2.36.0-1.fc25.x86_64
gdk-pixbuf2-modules-2.36.0-1.fc25.x86_64
librsvg2-2.40.16-2.fc25.x86_64

╶➤ ls -l /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders.cache
-rw-r--r--. 1 root root 2866 Nov 28 20:03 /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders.cache

╶➤ sudo dnf -y reinstall gdk-pixbuf2

╶➤ ls -l /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders.cache
-rw-r--r--. 1 root root 3186 Nov 28 20:14 /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders.cache

╶➤ diff -u loaders.cache.broken /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders.cache
--- loaders.cache.broken        2016-11-28 20:03:23.374389331 -0500
+++ /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders.cache      2016-11-28 20:14:01.962171724 -0500
@@ -10,6 +10,13 @@
 "gif" ""
 "GIF8" "" 100

+"/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so"
+"svg" 6 "gdk-pixbuf" "Scalable Vector Graphics" "LGPL"
+"image/svg+xml" "image/svg" "image/svg-xml" "image/vnd.adobe.svg+xml" "text/xml-svg" "image/svg+xml-compressed" ""
+"svg" "svgz" "svg.gz" ""
+" <svg" "*    " 100
+" <!DOCTYPE svg" "*             " 100
+
 "/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so"
 "xpm" 4 "gdk-pixbuf" "XPM" "LGPL"
 "image/x-xpixmap" ""


Now, the question of why this isn't working is still a mystery...  rpm -q --triggers shows nothing for the vast majority of packages, which is strange in itself, and I've confirmed that RPM never attempts to run gdk-pixbuf-query-loaders-64 to rebuild the cache while installing librsvg2, both via RPM debug logs and via strace of the entire process tree.

I suspect this warrants a separate bug -- the gnome-shell hang stands alone and the upstream fix is still relevant -- but not even sure what to open it against at the moment...

Similar issue on a fresh install of Fedora 25 server. When I try to authenticate, e.g. by starting virt-manager, I see the following pop up in journalctl -f:



 JS ERROR: Error: can't convert this._frame to an integer
                                                     Animation<._showFrame@resource:///org/gnome/shell/ui/animation.js:59
                                                     wrapper@resource:///org/gnome/gjs/modules/lang.js:178
                                                     Animation<.play@resource:///org/gnome/shell/ui/animation.js:34
                                                     wrapper@resource:///org/gnome/gjs/modules/lang.js:178
                                                     AuthenticationDialog<._setWorking@resource:///org/gnome/shell/ui/components/polkitAgent.js:195
                                                     wrapper@resource:///org/gnome/gjs/modules/lang.js:178
                                                     AuthenticationDialog<._updateSensitivity@resource:///org/gnome/shell/ui/components/polkitAgent.js:262
                                                     wrapper@resource:///org/gnome/gjs/modules/lang.js:178
                                                     AuthenticationDialog<._onEntryActivate@resource:///org/gnome/shell/ui/components/polkitAgent.js:267
                                                     wrapper@resource:///org/gnome/gjs/modules/lang.js:178


The install procedure was:
- Install Fedora 25 server
- dnf group install "Fedora Workstation" on top of it

The same procedure had worked on two other machines before, but the order of package install was different (e.g. on one, I had installed Hawaii Desktop first to reproduce another issue).

I also encounter (very frequent) random freezes when trying to unlock my lenovo T440s running Fedora 25. It seems unrelated to X/Wayland.

Concretely: I open my lid, enter my password, press enter, and it never logs in: the login screen completely freezes. I can still move the mouse, but cannot interact with anything anymore. I can still press CTRL+SHIFT+F<number> to switch to a terminal.

Once it's frozen, my only solution is to reboot the system.

I am also still occasionally experiencing this lockup on 3.22.x.

(In reply to Gwendal from comment #9)
> I also encounter (very frequent) random freezes when trying to unlock my
> lenovo T440s running Fedora 25. It seems unrelated to X/Wayland.
> 
> Concretely: I open my lid, enter my password, press enter, and it never logs
> in: the login screen completely freezes. I can still move the mouse, but
> cannot interact with anything anymore. I can still press
> CTRL+SHIFT+F<number> to switch to a terminal.
> 
> Once it's frozen, my only solution is to reboot the system.

I also have a T440s and I am experiencing the same problem you are describing, except it isn't happening very frequently.
The last time it happened I put the laptop to sleep using the power button and when I woke it up the login screen was functioning again. I was then able to input my password and continue with the same desktop session without rebooting.

(In reply to Dan Dragomir from comment #11)
> I also have a T440s and I am experiencing the same problem you are
> describing, except it isn't happening very frequently.
> The last time it happened I put the laptop to sleep using the power button
> and when I woke it up the login screen was functioning again. I was then
> able to input my password and continue with the same desktop session without
> rebooting.

If I see the problem again, I'll try to see if I can put the system to sleep. But from memory, I tried, and it didn't work. That's a desktop machine, though, and I think that the default configuration does not sleep when you press the power button.

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. 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 '25'.

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 25 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 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 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.