After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 767180 - Login screen bypassed for at least 20 seconds after awakening machine from suspend
Login screen bypassed for at least 20 seconds after awakening machine from su...
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
3.22.x
Other Linux
: Normal critical
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2016-06-02 19:56 UTC by Inactive account
Modified: 2021-07-05 14:45 UTC
See Also:
GNOME target: ---
GNOME version: 3.21/3.22



Description Inactive account 2016-06-02 19:56:45 UTC
Since upgrading to GNOME 3.20 on Ubuntu GNOME 16.04 I have noticed something rather worrying which has occurred twice so far, this is what I have observed:

1. After opening my laptop lid the screen either goes black or displays a frozen state of the shield opening or something similar

2. Then it suddenly shows Firefox (the last window I had open, though I did minimize it before suspending my machine my closing the laptop lid) and actually allows me to use my mouse to interact with it by going to a new tab, or really anything I want, I haven't tried to see if I am able to type in this state yet or not, but I will update this report the next time I manage to test it out. This is obviously a really bad thing for security as for at least 20 long seconds (each time it occurs it seems to last longer) it logs you straight back in and bypasses the login screen, though for some reason the title part of the window and everything above that are completely black as if someone just put a big black box over them.

3. I then suddenly see black and no Firefox (this black only lasts for a short period though), then I see what I see when I would normally log in for the first time (my background image coming in with that getting larger image with the top bar at the top of it), and then it's back to the normal locked screen as it should be.

The sequence of events (what I see on my screen) seems to vary between occasions, but the ability to interact with my machine without having to log in stays even though it at some point does register that it should really be taking me to the locked screen. And I have checked and if I for instance open a new tab and go to one of my bookmarks in Firefox during this strange bypassing period, when I properly log back in again (and find Firefox minimized as I left it) I find that that tab is still open so the changes are real and lasting.

I initially reported this issue here but thought I should also do so upstream: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1588521
Comment 1 Florian Müllner 2016-06-02 20:10:11 UTC
(In reply to cooks.go.hungry from comment #0)
> for some reason the title part of the window and everything above that 
> are completely black as if someone just put a big black box over them.
> 
> 3. I then suddenly see black and no Firefox (this black only lasts for a
> short period though), then I see what I see when I would normally log in for
> the first time (my background image coming in with that getting larger image
> with the top bar at the top of it), and then it's back to the normal locked
> screen as it should be.

That sounds like a crash and restart. Can you provide a backtrace?
Comment 2 Inactive account 2016-06-03 12:39:29 UTC
Just to let you know, I will provide a backtrace as soon as I can, I'm just having some slight issues with installing the debug symbols which is most likely being caused by a packaging issue... But I will provide with it as soon as my system lets me.
Comment 3 Inactive account 2016-06-04 20:00:16 UTC
Right, I'm hoping that I've fixed the issue with the debug symbols, now there appear to be two instances of gnome-shell running all the time, though one seems always to be using more RAM, which would you like the backtrace of? Both?
Comment 4 Inactive account 2016-06-04 21:13:09 UTC
Well, I found out the running it on one of them causes a total system crash... So I think I will run it on the other which doesn't cause such effects, and I will get back to you when I get the requested backtrace...
Comment 5 Florian Müllner 2016-06-05 07:57:36 UTC
One is probably run by gdm. The one that's crashing is the one in the user session, i.e. the other one. If you have systemd with coredumpctl enabled, the backtrace from the crash should be available, otherwise you'll need to reproduce the crash.
Comment 6 Inactive account 2016-06-05 14:29:14 UTC
Right, I am having some issues getting the backtrace using debug symbols and gdb due to downstream packaging issues so I'm not sure if I'm going to be able to do it that way... How do I check if coredumpctl is enabled and would the core dumps go to the standard place (/var/crash)? Also, is there not a more in-built way of logging this sort of thing in gnome-shell?
Comment 7 Florian Müllner 2016-06-05 15:03:23 UTC
(In reply to cooks.go.hungry from comment #6)
> How do I check if coredumpctl is enabled

Running "coredumpctl" without arguments should give you a list of available coredumps if installed and enabled.


> and would the core dumps go to the standard place (/var/crash)?

Whether coredumps are stored in the journal or on disk (and where) are subject to configuration. Usually you don't care and use the "coredumpctl" tool to show a dump.


> Also, is there not a more in-built way of logging this sort of thing in 
> gnome-shell?

No. A process that has crashed is no longer running, and thus cannot perform any actions.
Comment 8 Inactive account 2016-06-30 22:18:37 UTC
Well, the debug symbol route is not going very well due to many gnome-shell dependencies not having available debug symbol packages... But after the error just occurred there were some potentially relevant entries in syslog so I thought I would just add them here:

    Jun 30 22:51:02 <Computer-Name> org.gnome.Shell.desktop[1910]: (gnome-shell:1910): Gjs-WARNING **: JS ERROR: Error getting systemd inhibitor: Gio.IOErrorEnum: GDBus.Error:org.freedesktop.login1.OperationInProgress: The operation inhibition has been requested for is already running

    Jun 30 20:51:45 <Computer-Name> org.gnome.Shell.desktop[1910]: ** (gnome-shell:1910): CRITICAL **: remove_mnemonics: assertion 'label != NULL' failed

There were other entries between the two above, but as they didn't seem relevant I didn't include them. But these entries all came together and around the same time as the crash (I will also be doing as it instructs):

    Jun 30 22:52:18 <Computer-Name> kernel: [16090.619806] [drm] stuck on render ring
    Jun 30 22:52:18 <Computer-Name> kernel: [16090.620319] [drm] GPU HANG: ecode 6:0:0x84fefffc, in gnome-shell [1910], reason: Ring hung, action: reset
    Jun 30 22:52:18 <Computer-Name> kernel: [16090.620321] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
    Jun 30 22:52:18 <Computer-Name> kernel: [16090.620322] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel
    Jun 30 22:52:18 <Computer-Name> kernel: [16090.620323] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
    Jun 30 22:52:18 <Computer-Name> kernel: [16090.620324] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it.
    Jun 30 22:52:18 <Computer-Name> kernel: [16090.620325] [drm] GPU crash dump saved to /sys/class/drm/card0/error
    Jun 30 22:52:18 <Computer-Name> kernel: [16090.622412] drm/i915: Resetting chip after gpu hang
    Jun 30 22:52:24 <Computer-Name> kernel: [16096.656115] [drm] stuck on render ring
    Jun 30 22:52:24 <Computer-Name> kernel: [16096.656640] [drm] GPU HANG: ecode 6:0:0x84fefffc, in gnome-shell [1910], reason: Ring hung, action: reset
    Jun 30 22:52:24 <Computer-Name> kernel: [16096.658736] drm/i915: Resetting chip after gpu hang

I will have to confirm though whether the above errors come every time this crash occurs, or whether they just happened to come at the same time this time.
Comment 9 Inactive account 2016-07-09 20:05:39 UTC
I'm not sure if the above message has anything to do with this bug, I thought not at first (though after I posted the above) as I'm sure that it didn't log something like this to syslog when it happened again, but now I am not so sure as it did this time, though these could be two issues which have nothing to do with each other and it could just be a coincidence.

Anyway, as it is happening more now and more severely I want to have another crack with the debug symbols etc. Now, there are two gnome-shell processes running it seems, if I try to do it on one of them then everything just freezes, and if I try on the other it works, but not all of the dependencies seemingly have debug symbol packages so I don't know if that would be an issue? Which of the gnome-shell processes would you like me to do it on? If both, then would it still freeze if I did it, say, from a TTY? As then the freezing probably wouldn't affect the displaying of how it is going and the ability to make it start recording and probably thus unfreeze the frozen session.

I will also be speaking with my distribution team about this, but I just wanted to check those few things with you first.
Comment 10 Inactive account 2018-07-21 13:13:48 UTC
This issue does not seem to exist any more under GNOME 3.28 on Arch, however perhaps it still exists in other distrobutions: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1532508
Comment 11 GNOME Infrastructure Team 2021-07-05 14:45:30 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.