GNOME Bugzilla – Bug 704644
Login constantly hangs, freezes, crashes,...
Last modified: 2014-11-09 20:25:30 UTC
Login constantly hangs, freezes, crashes and does whatever things with GDM 3.8.3/Gnome 3.8.x. I leave my laptop running for days with just suspend, and every 5th wake up from suspend or so I can basically just kill every gnome-related/gdm-related process and start the whole thing over because it just locks up. Locking up can happen in a variety of cases: 1.) just grey backgronud but no login stuff or any controls visible except hte top bar, 2.) login form visible and usable, but after entering credentials and pressing eenter, the input form goes greyed out but nothing happens (stays greyed out and locked up forever). (that is the two situations I can recall immediately) This is very annoying because unlike a freezing gnome shell when I'm logged in, I cannot simply restart GDM without losing my complete session with all open programs. As you can assume, not restarting and just suspending the laptop has the VERY PURPOSE of NOT losing all opened programs and such.
As an additional information, the lockup usually doesn't occur right away (everything appears to be fine after the wake up at first), but as soon as I attempt to login.
is there anything interesting in /var/log/gdm/ or /var/log/Xorg.*.log or the output of the "dmesg" command?
someone came by my cube earlier today with similar symptoms. backtrace showed the shell was deadlocked waiting on a g_cancellable mutex in g_cancellable_cancel and g_cancellable_release_fd. The person with the offending laptop said he was going to file the backtrace in bugzilla, so i'll link to it when he does.
I feel this is related to me typing too fast and pressing enter when gdm or that login form thing still want to do something (e.g. finish the animations?). Also this did never occur in the previous Fedora/GNOME iteration (where those new fancy animations weren't present yet to that extent, most prominently that new "drag up" cover thing). Nothing interesting in the log files to be found. (checked gdm, dmesg, X) It appears to happen more often after wake up from suspend to ram, but I also had it happen after a while of idling locked without any suspend involved. And it's not exactly rare here, so I suppose if you tried for a while it shouldn't be too hard to reproduce (a slower laptop as testing machine and typing the password fast might help, assuming this is some sort of race condition).
It just recently happened again and I tried to attach gdb to gnome-shell, but gdb itself froze with the following backtrace:
+ Trace 232401
When killing the hanging gdb and gnome-shell and restarting gnome-shell, I successfully managed to be logged in without losing my session. (So apparently the hang happened after the login stuff itself was processed)
Today I got another hang after login (when pressing enter after entering the password, the whole login form just stayed there forever), and this time I managed to attach gdb and get a backtrace:
+ Trace 232610
I had another case where I couldn't attach gdb to the shell (gdb attaching would hang). The STAT entry of ps aux of gnome-shell was: Sl After attempting to kill -9 it, it went to: D In the end, the only thing I could do was kill the whole gnome-session off. I will change the component to "gnome-shell" because in all cases I examined more thoroughly, that appears to be the program that got stuck. Comment 3 seems to hint at that aswell. Sorry if this is the wrong thing to do, but it appears this was originally misfiled on my behalf and I just hope to get this into the right hands so something can be done about it! (this bug is a time eater due to all the programs being gone which I need to reopen and also it sadly is a frequent issue on my work laptop when resuming from suspend)
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 733068 ***