Bug 1443206 - gnome-shell consistently crashes in the middle of first-login gnome-initial-setup
Summary: gnome-shell consistently crashes in the middle of first-login gnome-initial-s...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libgweather
Version: 26
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
: 1442624 1442680 1446861 1448317 1448869 1451713 (view as bug list)
Depends On:
Blocks: F26BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2017-04-18 18:23 UTC by Adam Williamson
Modified: 2017-06-03 17:37 UTC (History)
19 users (show)

Fixed In Version: libgweather-3.24.0-3.fc26
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-06-03 17:37:39 UTC


Attachments (Terms of Use)
abrt-generated backtrace (86.62 KB, text/plain)
2017-04-18 22:02 UTC, Adam Williamson
no flags Details


Links
System ID Priority Status Summary Last Updated
GNOME Bugzilla 780278 None None None 2017-04-27 12:00:25 UTC
GNOME Bugzilla 781828 None None None 2017-04-27 12:00:50 UTC
Red Hat Bugzilla 1446879 None None None Never

Internal Links: 1446879

Description Adam Williamson 2017-04-18 18:23:57 UTC
The first time you log into GNOME Shell as a user, an instance of gnome-initial-setup runs. Currently, on Fedora 26 and Fedora Rawhide, gnome-shell will always crash - dumping you back to GDM - part-way through this g-i-s run. It always crashes after the 'Privacy' screen, presumably while loading the next screen.

I'm still trying to get a fully usable backtrace from the crash (it requires a large quantity of debuginfo...), but the issue is trivial to reproduce:

1) Get a recent Rawhide or 26 Workstation live nightly - e.g. https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20170418.n.0/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-Rawhide-20170418.n.0.iso

2) Do an install, creating a user account during install

3) Boot the installed system, log in as the user you created during install

4) Click through g-i-s and observe that the desktop session crashes back to GDM part way through

Proposing as a Beta blocker per Alpha criterion "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility." - you never really reach a 'working desktop' if you create a user during install, unless you short-circuit g-i-s somehow.

Comment 1 Adam Williamson 2017-04-18 18:29:31 UTC
The backtrace starts in libgweather:

,   "stacktrace":
      [ {   "crash_thread": true
        ,   "frames":
              [ {   "address": 140170033566276
                ,   "build_id": "086e9740d07546cd66b582255da6859ba74f77aa"
                ,   "build_id_offset": 90692
                ,   "function_name": "_gweather_location_update_weather_location"
                ,   "file_name": "/lib64/libgweather-3.so.6"
                }
              , {   "address": 140170033520326
                ,   "build_id": "086e9740d07546cd66b582255da6859ba74f77aa"
                ,   "build_id_offset": 44742
                ,   "function_name": "gweather_info_set_location_internal"
                ,   "file_name": "/lib64/libgweather-3.so.6"
                }
              , {   "address": 140170033537453
                ,   "build_id": "086e9740d07546cd66b582255da6859ba74f77aa"
                ,   "build_id_offset": 61869
                ,   "function_name": "gweather_info_set_location"
                ,   "file_name": "/lib64/libgweather-3.so.6"
                }
...

which I find rather interesting. I have a theory: I think the problem may be g-i-s running in the wrong mode. g-i-s has two modes, one that gets used if no user account exists on boot (call it 'no-user-mode') and one that gets run on first login with a new user account (call it 'first-login-mode'). I think the problem may be that it's running in no-user-mode when it should be running in first-login-mode.

In no-user-mode, the screen after Privacy is Time Zone. In first-login-mode, the Time Zone screen *should* be skipped and the Online Accounts screen should come after Privacy. But here we're running on first login of a new user and we have a backtrace running through libgweather, which obviously would be used for the Time Zone screen, but doesn't seem to have any relevance to the Online Accounts screen.

So could the problem here be that g-i-s is incorrectly running in 'no-user-mode' during a user session?

Comment 3 Matthias Clasen 2017-04-18 21:39:05 UTC
that theory doesn't make any sense to me, given hat the stacktrace is from gnome-shell, not from gnome-initial-setup. It is, right ? You're not exactly saying...

It should be easy to find out if g-i-s is running in first-boot or first-login mode. Just look at ps and see the commandline options

Comment 4 Adam Williamson 2017-04-18 21:59:19 UTC
Oh, yes. Good point.

And yeah, I checked the ps output after posting that last comment, and it shows the appropriate parameter is there.

I'm still trying to get the full backtrace.

Comment 5 Adam Williamson 2017-04-18 22:00:05 UTC
Gah, once again, abrt gives me "Reporting disabled because the backtrace is unusable". Just fuck off, abrt.

Comment 6 Adam Williamson 2017-04-18 22:02:05 UTC
Created attachment 1272422 [details]
abrt-generated backtrace

Here's the backtrace that gnome-abrt generates for the crash. I can't do a full ABRT report because it claims the backtrace is 'unusable'.

Comment 7 Florian Müllner 2017-04-19 11:42:20 UTC
https://bugzilla.gnome.org/show_bug.cgi?id=780278 looks relevant - we probably want to include the fix downstream until we get a new tarball.

Comment 8 Adam Williamson 2017-04-19 18:34:05 UTC
The timeframes don't quite match up (this didn't start showing up on March 21st in Fedora, when the package was built), but it's possible that gnome-shell or g-i-s behaviour changed to hit the crash in 3.24.1, I guess. I'll build a test package and try it out. Thanks for the pointer.

Comment 9 Adam Williamson 2017-04-19 19:54:40 UTC
Sadly, that doesn't help. I built a package with the patch applied, installed it on the system I'm using to test this, rebooted, and ran through g-i-s again (it runs on every login, because it never *completes*), and it crashed again in the usual place.

Comment 10 Chris Murphy 2017-04-19 23:59:05 UTC
I'm pretty sure this is the same bug I've been hitting for a few days now. Bug 1442631. I've got a full coredump referenced in that bug. And it's happening on very old and very new i915 hardware, that's also referenced.

Comment 11 Adam Williamson 2017-04-20 00:09:24 UTC
I'm not so sure about that, but we'll see. On my test system, the shell works fine so long as I don't click through to the offending step of gnome-initial-setup. It doesn't crash on login.

Comment 12 Adam Williamson 2017-04-20 00:09:56 UTC
Though - I suppose the impact of g-i-s could be that, if it's running, until you get through the Privacy step, Shell doesn't try and look up the weather?

Comment 13 Adam Williamson 2017-04-20 00:11:13 UTC
Aha! Yes. That seems plausible. If I don't just click through g-i-s, but on the Privacy screen I turn off the 'Location Services' setting, then I can complete the rest of g-i-s without the Shell crashing.

Comment 14 Chris Murphy 2017-04-20 00:19:23 UTC
Yea I think that's it. I've updated my bug, playing around with the Weather app I was getting various crashes, and then speculate that maybe the weather or location updates that happen periodically are what trigger my 1-2x a day crash.

Comment 15 Alessio 2017-04-23 05:00:15 UTC
*** Bug 1442680 has been marked as a duplicate of this bug. ***

Comment 16 Alessio 2017-04-23 08:56:15 UTC
I've noted a strange thing, but I'm unsure.
When I first install Fedora-Workstation-Live-x86_64-26-20170420.n.0.iso on bare metal, I don't remember I have hit this issue (gnome-shell will always crash dumping you back to GDM during gnome initial setup).
Using virt-manager or gnome boxes, I hit the issue.
Testing again with Oracle Virtual Box, the initial setup works without dumping back to GDM.
Maybe I'm wrong.

Comment 17 Joachim Frieben 2017-04-23 12:21:31 UTC
The crash occurs when confirming the privacy settings suggested by gnome-initial-setup (only) in a GNOME on Wayland session. On the contrary, in a GNOME on Xorg setting, the same action triggers the temporary blanking of the entire screen but after a short instant, the GNOME desktop reappears and gnome-initial-setup has moved successfully to the final page. So, this is a -Wayland- issue!

The output of command 'demesg' returns the error message: "gnome-shell[1411]: segfault at 38 ip 00007ffa270f12f4 sp 00007fffc1cf8540 error 4 in libgweather-3.so.6.6.0[7ffa270db000+22000]".

Unfortunately, the backtrace is reported to be unusable even when using local debuginfo files. The backtrace might be unusable because libicudata.so.57.1.debug has been built without debug info, see bug 1444427.

Comment 18 Joachim Frieben 2017-04-23 12:24:05 UTC
(In reply to Alessio from comment #16)
I encounter this issue when running a virtual guest session in gnome-boxes using the QXL video device.

Comment 19 Alessio 2017-04-24 03:56:08 UTC
(In reply to Joachim Frieben from comment #17)
> The crash occurs when confirming the privacy settings suggested by
> gnome-initial-setup (only) in a GNOME on Wayland session. On the contrary,
> in a GNOME on Xorg setting, the same action triggers the temporary blanking
> of the entire screen but after a short instant, the GNOME desktop reappears
> and gnome-initial-setup has moved successfully to the final page. So, this
> is a -Wayland- issue!

Yes. Same issue. If I start the session using Xorg, the behaviour is the same that you have described: temporary blanking of the entire screen but after a short instant, the GNOME desktop reappears, but I can continue with gnome initial setup.

Comment 20 Geoffrey Marr 2017-04-24 19:12:27 UTC
Discussed during the 2017-04-24 blocker review meeting: [1]

The decision to classify this bug as an AcceptedBlocker was made as it violates the following blocker criteria:

"A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility."

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2017-04-24/f26-blocker-review.2017-04-24-16.00.txt

Comment 21 Florian Müllner 2017-04-27 12:00:26 UTC
I found another memory issue in libgweather, with that fix and the one mentioned in comment #7, I can successfully complete initial-setup in a VM. Can someone else confirm that

  https://koji.fedoraproject.org/koji/taskinfo?taskID=19232686

fixes the issue?

Comment 22 Alessio 2017-04-27 16:47:43 UTC
(In reply to Florian Müllner from comment #21)
> fixes the issue?

Yes! Now it works. 
I have installed the rpm and I had to reboot, logout and login is not enough, right?

Thank you.

Comment 23 Adam Williamson 2017-04-27 20:59:24 UTC
Yep, seems to work here too. Thanks! Can you submit an update?

Comment 24 Fedora Update System 2017-04-28 11:16:08 UTC
libgweather-3.24.0-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-889e4f475c

Comment 25 Fedora Update System 2017-04-30 03:51:42 UTC
libgweather-3.24.0-2.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-889e4f475c

Comment 26 Adam Williamson 2017-05-01 17:30:52 UTC
Multiple people in the update are reporting running into a subsequent crash:

https://bugzilla.redhat.com/show_bug.cgi?id=1446879

Comment 27 Chris Murphy 2017-05-04 00:24:48 UTC
I'm hitting this with Fedora-Workstation-Live-x86_64-26-20170502.n.0.iso which has libgweather-3.24.0-1.fc26.x86_64.

Following this and reboot

[chris@localhost-live ~]$ sudo dnf update https://kojipkgs.fedoraproject.org//packages/libgweather/3.24.0/2.fc26/x86_64/libgweather-3.24.0-2.fc26.x86_64.rpm


Crash does not occur in g-i-s as before.

Comment 28 Saurav Sengupta 2017-05-04 13:33:25 UTC
As far as I can make out, it seems that the crash is not caused by gnome-initial-setup itself, but occurs whenever location services are enabled or disabled in GNOME. For example, it occurs if Location Services is switched on/off in Control Centre, Privacy, even when g-i-s is not running. libgweather-3.24.0-2.fc26 was not available in the updates-testing repository, so I upgraded with a manual download, but it still crashed.

The crash occurs if some location-aware applications are installed; in particular, GNOME Maps and/or GNOME Weather. If both of those apps are removed, the crash does not occur.

Comment 29 Adam Williamson 2017-05-04 16:20:13 UTC
Yes, multiple people reported they were seeing a later crash with 3.24.0-2, which is why it's not in updates-testing; the update was unpushed due to negative feedback. fmuellner is looking into it now.

Comment 30 Adam Williamson 2017-05-04 16:21:44 UTC
The subsequent crash is https://bugzilla.redhat.com/show_bug.cgi?id=1446879 .

Comment 31 Saurav Sengupta 2017-05-04 17:33:32 UTC
Bug #1446879 was not what I encountered; I encountered this one again as long as GNOME Maps and/or GNOME Weather was installed. In this scenario, this crash occurs whenever I try to turn Location Services on/off. The crash doesn't occur on Location on/off if both these apps are uninstalled.

Comment 32 Chris Murphy 2017-05-04 17:45:27 UTC
I'm getting the same inconsistent crash as comment 31. Turn off location services, no crash. Turn it back on, crash. Log back in and go to location services, turn off and on, off and on, off and on, no crash. Abrt doesn't record the crash at all, but coredumpctl has a 51MB coredump file for gnome-shell. The trace isn't exactly comparable to bug 1446879 formatting wise, but has some of the same .so files.

Comment 33 Alessio 2017-05-09 21:05:03 UTC
*** Bug 1448869 has been marked as a duplicate of this bug. ***

Comment 34 Alessio 2017-05-09 21:06:28 UTC
*** Bug 1448317 has been marked as a duplicate of this bug. ***

Comment 35 Alessio 2017-05-14 19:16:30 UTC
Just a note.
If during the installation process I don't create a user, next to reboot initial-setup will start, asking to set up, among other things, Location Services and default user creation.
During this process there are no issues like the one when initial-setup start after the first login (when the default user was created during the installation process).

Comment 36 Joachim Frieben 2017-05-18 07:34:34 UTC
Since the initial report, GNOME 3.24.2 with many updated packages has been released, and it seems that libgweather-3.24.0-2.fc26 now actually does the job: both in a live session booting from image Fedora-Workstation-Live-x86_64-26-20170516.n.0.iso and in a fully updated Fedora 26 guest, gnome-initial-setup executes without any issue after upgrading to libgweather-3.24.0-2.fc26.
Package libgweather-3.24.0-2.fc26 should be simply pushed to bodhi once again.

Comment 37 Alessio 2017-05-18 12:57:03 UTC
(In reply to Joachim Frieben from comment #36)
> Since the initial report, GNOME 3.24.2 with many updated packages has been

Using Fedora-Workstation-Live-x86_64-26-20170517.n.0.iso as is, it continues to crash. Installed libgweather-3.24.0-2.fc26 and only this package, rebooted the system, and initial-setup crashed; at the following login it worked. Weather app worked as well. Created a new user: no crash at the first login.

Again. 
Fresh install of Fedora-Workstation-Live-x86_64-26-20170517.n.0.iso
I DIDN'T login. From a tty I logged in as root. Installed libgweather-3.24.0-2.fc26. Rebooted. Logged in with the user created during the installation process. All is working as expected. But... gnome shell killed by signal 11 after a short time. And gnome-shell continues to crash when in gnome weather I turn on and off Automatic Location.

At this point: dnf update. Reboot.
Gnome-shell continues to crash when, for instance, in gnome weather I turn off then on the Automatic location.

For me nothing ha changed.

Comment 38 Florian Müllner 2017-05-19 11:12:05 UTC
(In reply to Alessio from comment #37)
> (In reply to Joachim Frieben from comment #36)
> > Since the initial report, GNOME 3.24.2 with many updated packages has been
> 
> Using Fedora-Workstation-Live-x86_64-26-20170517.n.0.iso as is, it continues
> to crash. Installed libgweather-3.24.0-2.fc26 and only this package
> [...]
> For me nothing ha changed.

There have been some fixes in gjs' memory management which may make a difference as well.

Comment 39 Florian Müllner 2017-05-19 11:18:49 UTC
*** Bug 1451713 has been marked as a duplicate of this bug. ***

Comment 40 Joachim Frieben 2017-05-19 14:37:18 UTC
As reported in bug 1446879, upgrading to bug libgweather-3.24.0-2.fc26 does fix -this- bug 1443206 but still triggers bug 1446879 instead which is the current situation. The crash can be reproduced most of the time but -not- always by removing file .config/gnome-initial-setup and going through the successive steps of gnome-initial-setup. Comment 36 therefore rather belonged to bug 1446879.

Comment 41 eric 2017-05-22 22:53:01 UTC
I have the same problem when the initial f26 install runs gnome-initial-setup, it fails to complete and exit to login prompt. 
Installing libgweather-3.24.0.2.fc26 would allow the gnome-initial-setup to complete successfully.

Comment 42 Adam Williamson 2017-05-23 16:02:30 UTC
*** Bug 1442624 has been marked as a duplicate of this bug. ***

Comment 43 Adam Williamson 2017-05-23 23:17:58 UTC
So I'm resetting this to POST to accurately reflect current status: we have a fix for this, but the update got rejected because testers ran into #1446879 .

According to fmuellner, #1446879 isn't really any sort of regression; libgweather 3.24.0-1.fc26 could also be susceptible to that bug. We just weren't seeing it because *this* bug would cause an earlier crash.

Given that, I'm going to suggest we should re-submit the 3.24.0-2.fc26 update, as it clearly *does* fix this bug, and doesn't make anything else worse. We can include special instructions not to reject it just because of #1446879 . Does this seem reasonable?

Comment 44 Fedora Update System 2017-05-23 23:28:13 UTC
libgweather-3.24.0-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-889e4f475c

Comment 45 Link Dupont 2017-05-24 04:41:08 UTC
*** Bug 1446861 has been marked as a duplicate of this bug. ***

Comment 46 Adam Williamson 2017-05-24 16:31:22 UTC
I found another likely-looking fix upstream:

https://git.gnome.org/browse/libgweather/commit/?id=bbe6f7c1c85628336536bcec6684d281656a3739

so I've done a new build, -3:

https://koji.fedoraproject.org/koji/buildinfo?buildID=897407

Can folks please try with that and report how it works for them? Thanks!

Comment 47 Tom Hughes 2017-05-24 18:57:49 UTC
I can confirm that I was able to complete initial setup using the -3 build without the shell crashing.

Comment 48 Adam Williamson 2017-05-24 20:11:12 UTC
Did you see any subsequent crashes (like 1446879)?

Comment 49 Tom Hughes 2017-05-24 20:14:13 UTC
Well nothing so far, in the hour or so since I updated.

Comment 50 Saurav Sengupta 2017-05-25 09:47:08 UTC
Build 3 is working properly for me too. No crashes in g-i-s, and no crashes when switching Location Services on/off, on both Wayland and X. No other crashes either (1446879). Location Services, GNOME Weather, GNOME Maps, and GNOME Initial Setup are all working fine.

Comment 51 Fedora Update System 2017-05-25 19:16:23 UTC
libgweather-3.24.0-3.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-889e4f475c

Comment 52 Fedora Update System 2017-06-03 17:37:39 UTC
libgweather-3.24.0-3.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.