Bug 1718807

Summary: session frozen after several suspends
Product: Red Hat Enterprise Linux 8 Reporter: Martin Krajnak <mkrajnak>
Component: gnome-shellAssignee: Florian Müllner <fmuellner>
Status: CLOSED DUPLICATE QA Contact: Desktop QE <desktop-qa-list>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 8.1CC: fmuellner, jadahl, jkoten, mclasen, tpelka, vbenes, wchadwic
Target Milestone: rcKeywords: Regression
Target Release: 8.1   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-07-24 13:22:37 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1678350    
Attachments:
Description Flags
t a a bt
none
gdm process t a a bt
none
I have a new backtrace that has few clock items again, this is gnome-shell under X (frozen BEFORE suspend) and killable via kill -9 $(pidof GS) so you can recover session none

Description Martin Krajnak 2019-06-10 09:32:20 UTC 
Description of problem:
Gnome session freezes after up to 4 suspends via closing the laptop lid. I was able to change console via Alt-F3, finding out there are 2 processes, consuming CPU heavilly:

 1861 gdm       20   0 3084784 141592  80356 R 106.7   0.9   2:41.87 gnome-shell                                                                                                                                                                
 3022 mkrajnak  20   0 3481100 185760  83764 R 106.7   1.2   2:48.40 gnome-shell 

after 2-3 minutes examining the logs even the console became frozen and the only action I could do is reboot the laptop via hardware button.

Version-Release number of selected component (if applicable):
gnome-shell-3.32.2-2.el8.x86_64
gdm-3.28.3-20.el8.x86_64
kernel-4.18.0-103.el8.x86_6

How reproducible:
almost always on 3rd suspend

Steps to Reproduce:
1.Suspend and wake laptop up to 3 times

Actual results:
Frozen gnome-session as user left it before suspend, no gdm password dialog 


Someting from the journal (more will be provided)

Jun 10 11:09:26 localhost.localdomain gsd-power[3158]: Error setting property 'PowerSaveMode' on interface org.gnome.Mutter.DisplayConfig: Timeout was reached (g-io-error-quark, 24)
Jun 10 11:09:33 localhost.localdomain gsd-power[3158]: Error setting property 'PowerSaveMode' on interface org.gnome.Mutter.DisplayConfig: Timeout was reached (g-io-error-quark, 24)
Jun 10 11:09:33 localhost.localdomain gsd-power[2335]: Error setting property 'PowerSaveMode' on interface org.gnome.Mutter.DisplayConfig: Timeout was reached (g-io-error-quark, 24)

Expected results:
Laptop should wake as expected

Additional info:
Comment 3 Florian Müllner 2019-06-11 14:34:42 UTC 
(In reply to Martin Krajnak from comment #0)

> Someting from the journal (more will be provided)
> 
> Jun 10 11:09:26 localhost.localdomain gsd-power[3158]: Error setting
> property 'PowerSaveMode' on interface org.gnome.Mutter.DisplayConfig:
> Timeout was reached (g-io-error-quark, 24)

I'm not sure those messages are relevant - the D-Bus requests are handled by the mutter/gnome-shell process, so if that is frozen for some reason (infinite loop or something), then it's expected that the requests cannot be handled and time out.

Some things that may help:

 - turn off extensions (at least topIcons, the log shows it's incompatible with the rebased shell)

 - attach gdb to the gnome-shell process (from a TTY or SSH connection); if it is an infinite loop, a backtrace may tell us where it is

 - run `call gjs_dumpstack()` in gdb, in case the problem is in javascript code
Comment 4 Martin Krajnak 2019-06-11 15:10:32 UTC 
So far I Disabled all extensions and problem persists. 

I rather ask before doing something wrong, so please:

1. I see two gnome-shell processes, one owned by user(me), one owned by gdm, which one should I attach the gdb to ?

2. should I just run the gdb --pid=n and then just provide stack traces ?
I am not sure how to debug in this situation because there is no crash only freeze, 
so is `call gjs_dumpstack()` all I need when it freezes ?
Comment 5 Martin Krajnak 2019-06-12 12:32:48 UTC 
Created attachment 1579820 [details]
t a a bt

So far I obtained `t a a bt` from gdb attached to user process user process,

I installed as many debug info packages as I could since gnome-shell is probably touching everything but `call gjs_dumpstack()` is returning nothing at all

Again, extensions were completely disabled.
Comment 6 Martin Krajnak 2019-06-12 12:42:45 UTC 
Created attachment 1579825 [details]
gdm process t a a bt

same info from the gnome-shell process owned by gdm
Comment 17 Vladimir Benes 2019-07-18 08:33:05 UTC 
Created attachment 1591726 [details]
I have a new backtrace that has few clock items again, this is gnome-shell under X (frozen BEFORE suspend) and killable via kill -9 $(pidof GS) so you can recover session
Comment 18 Martin Krajnak 2019-07-24 12:17:53 UTC 
Hello Florian, 

thanks for the gnome-desktop3-3.32.2-2.el8.x86_64, so far it looks that it fixes the issue, can we expect permanent build ?
Comment 19 Florian Müllner 2019-07-24 13:22:37 UTC 
No. Ray identified the real issue in bug 1724551, marking this as a duplicate.

*** This bug has been marked as a duplicate of bug 1724551 ***