Bug 1443206

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?

I wonder if https://git.gnome.org/browse/gnome-initial-setup/commit/?id=fd8ad0fdc1dcf6d82a298ce375654ae657afd10b is related to this...see https://bugzilla.gnome.org/show_bug.cgi?id=780362 ...

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

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.

Gah, once again, abrt gives me "Reporting disabled because the backtrace is unusable". Just fuck off, abrt.

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'.

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.

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.

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.

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.

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.

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?

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.

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.

*** Bug 1442680 has been marked as a duplicate of this bug. ***

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.

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.

(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.

(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.

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

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?

(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.

Yep, seems to work here too. Thanks! Can you submit an update?

libgweather-3.24.0-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-889e4f475c

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

Multiple people in the update are reporting running into a subsequent crash:

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

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.

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.

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.

The subsequent crash is https://bugzilla.redhat.com/show_bug.cgi?id=1446879 .

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.

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.

*** Bug 1448869 has been marked as a duplicate of this bug. ***

*** Bug 1448317 has been marked as a duplicate of this bug. ***

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).

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.

(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.

(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.

*** Bug 1451713 has been marked as a duplicate of this bug. ***

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.

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.

*** Bug 1442624 has been marked as a duplicate of this bug. ***

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?

libgweather-3.24.0-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-889e4f475c

*** Bug 1446861 has been marked as a duplicate of this bug. ***

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!

I can confirm that I was able to complete initial setup using the -3 build without the shell crashing.

Did you see any subsequent crashes (like 1446879)?

Well nothing so far, in the hour or so since I updated.

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.

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

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.