Version-Release number of selected component:
runlevel: N 5
Created attachment 1275243 [details]
Created attachment 1275244 [details]
Created attachment 1275245 [details]
Created attachment 1275246 [details]
Created attachment 1275247 [details]
Created attachment 1275248 [details]
Created attachment 1275249 [details]
Created attachment 1275250 [details]
Created attachment 1275251 [details]
Created attachment 1275252 [details]
Created attachment 1275253 [details]
Created attachment 1275254 [details]
Crash occurred after upgrading to libgweather-3.24.0-2.fc26.
I might have hit this also but abrt doesn't have any items for the crash. Coredumpctl has an entry with a 51MB coredump file. The call trace is:
[chris@f26h ~]$ coredumpctl info 1736
PID: 1736 (gnome-shell)
UID: 1000 (chris)
GID: 1000 (chris)
Signal: 11 (SEGV)
Timestamp: Thu 2017-05-04 11:38:01 MDT (1min 51s ago)
Command Line: /usr/bin/gnome-shell
Control Group: /user.slice/user-1000.slice/session-2.scope
Owner UID: 1000 (chris)
Boot ID: 977217400dc642d39f90ec793ae8d144
Machine ID: 9cab11f07c734f978efb1cdf0d26911e
Message: Process 1736 (gnome-shell) of user 1000 dumped core.
Stack trace of thread 1736:
#0 0x00007fce6b0f9d90 foreach_city.part.4.constprop.7 (libgweather-3.so.6)
#1 0x00007fce6b0f9de8 foreach_city.part.4.constprop.7 (libgweather-3.so.6)
#2 0x00007fce6b0f9de8 foreach_city.part.4.constprop.7 (libgweather-3.so.6)
#3 0x00007fce6b0f9de8 foreach_city.part.4.constprop.7 (libgweather-3.so.6)
#4 0x00007fce6b0f9de8 foreach_city.part.4.constprop.7 (libgweather-3.so.6)
#5 0x00007fce6b0f9de8 foreach_city.part.4.constprop.7 (libgweather-3.so.6)
#6 0x00007fce6b0f9de8 foreach_city.part.4.constprop.7 (libgweather-3.so.6)
#7 0x00007fce6b0f9e92 gweather_location_find_nearest_city (libgweather-3.so.6)
#8 0x00007fce6b0fb193 gweather_location_new_detached (libgweather-3.so.6)
#9 0x00007fcebbc54bde ffi_call_unix64 (libffi.so.6)
#10 0x00007fcebbc5454f ffi_call (libffi.so.6)
#11 0x00007fcec63590cc n/a (libgjs.so.0)
#12 0x00007fcec635a876 n/a (libgjs.so.0)
#13 0x00007fcebb7746a8 _ZN2js6InvokeEP9JSContextN2JS8CallArgsENS_14MaybeConstructE (libmozjs-38.so)
#14 0x00007fcebb76a4cd _ZL9InterpretP9JSContextRN2js8RunStateE (libmozjs-38.so)
#15 0x00007fcebb774324 _ZN2js9RunScriptEP9JSContextRNS_8RunStateE (libmozjs-38.so)
#16 0x00007fcebb774614 _ZN2js6InvokeEP9JSContextN2JS8CallArgsENS_14MaybeConstructE (libmozjs-38.so)
#17 0x00007fcebb775243 _ZN2js6InvokeEP9JSContextRKN2JS5ValueES5_jPS4_NS2_13MutableHandleIS3_EE (libmozjs-38.so)
#18 0x00007fcebb9cdbfb _ZN2js3jit14InvokeFunctionEP9JSContextN2JS6HandleIP8JSObjectEEjPNS3_5ValueES9_ (libmozjs-38.so)
#19 0x00007fcec79c2134 n/a (n/a)
Duh. Might help to report how I got that crash. I went to location services, clicked it off, no crash. Clicked it back on, got the above crash. Logged back in and tried to reproduce, turning location services off then on, off then on, multiple times, no crash.
How about running the gnome-shell under valgrind? If it is a sporadic memory-related crasher, valgrind should be able to find it.
It doesn't seem that 'sporadic', we had four reports within hours of the update being pushed to testing: https://bodhi.fedoraproject.org/updates/FEDORA-2017-889e4f475c
Ping - we could really do with some movement on this? It's effectively blocking Beta, and we're in Beta freeze and 8 days from Beta go/no-go...
Joachim, Chris, I guess it might help if you have specific steps for reproducing the bug starting from scratch? Do either of you have that?
(In reply to Adam Williamson from comment #18)
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.
That...seems quite unlikely to me. It seems much more likely the crash only happens in some certain specific situation you're no longer in.
I did test the update when it first came out, and g-i-s completed fine for me and I didn't see a subsequent crash. So I think there was some kind of configuration difference involved.
I'd be OK with pushing the update again and seeing if people see crashes again, but I'd be surprised if this crash really has magically disappeared...
Indeed, this issue can be triggered frequently but -not- always in current Fedora 26 (including libgweather-3.24.0-2.fc26) by removing file .config/gnome-initial-setup-done and going through the individual steps of gnome-initial-setup.
So I just re-tested this and did indeed manage to hit this crash. I installed a current Workstation live, updated libgweather to 3.24.0-2.fc26 in a chroot before booting the installed system, and booted the installed system and logged in. The g-i-s run completed successfully, but shortly after it had concluded - with the system just sitting idle at the desktop - Shell crashed back to GDM, with a backtrace that looks very much like Joachim's (though abrt, for some reason, decided it was a dupe of #1133131 , despite the backtrace looking nothing like that bug at all):
Stack trace of thread 1758:
#0 0x00007f3cb5376fb6 __libc_free (libc.so.6)
#1 0x00007f3cb6ed3b7e g_free (libglib-2.0.so.0)
#2 0x00007f3c88eefdea gweather_location_unref (libgweather-3.so.6)
#3 0x00007f3cb71a440b g_boxed_free (libgobject-2.0.so.0)
#4 0x00007f3cbe68ad26 n/a (libgjs.so.0)
#5 0x00007f3cb3daf563 _ZL14FinalizeArenasPN2js6FreeOpEPPNS_2gc11ArenaHeaderERNS2_15SortedArenaL
#6 0x00007f3cb3e0a2b3 _ZN2js2gc10ArenaLists16forceFinalizeNowEPNS_6FreeOpENS0_9AllocKindENS1_14
#7 0x00007f3cb3db0831 _ZN2js2gc10ArenaLists30queueForegroundObjectsForSweepEPNS_6FreeOpE (libmo
#8 0x00007f3cb3dc71e9 _ZN2js2gc9GCRuntime22beginSweepingZoneGroupEv (libmozjs-38.so)
#9 0x00007f3cb3dc79c8 _ZN2js2gc9GCRuntime15beginSweepPhaseEb (libmozjs-38.so)
#10 0x00007f3cb3dc9be3 _ZN2js2gc9GCRuntime23incrementalCollectSliceERNS_11SliceBudgetEN2JS8gcrea
#11 0x00007f3cb3dca5d2 _ZN2js2gc9GCRuntime7gcCycleEbRNS_11SliceBudgetEN2JS8gcreason6ReasonE (lib
#12 0x00007f3cb3dca82d _ZN2js2gc9GCRuntime7collectEbNS_11SliceBudgetEN2JS8gcreason6ReasonE (libm
#13 0x00007f3cbe6b2739 gjs_schedule_gc_if_needed (libgjs.so.0)
#14 0x00007f3cbe6b27a4 gjs_call_function_value (libgjs.so.0)
#15 0x00007f3cbe68d895 gjs_closure_invoke (libgjs.so.0)
#16 0x00007f3cbe6a556e n/a (libgjs.so.0)
#17 0x00007f3cb71a630d g_closure_invoke (libgobject-2.0.so.0)
#18 0x00007f3cb71b898e signal_emit_unlocked_R (libgobject-2.0.so.0)
#19 0x00007f3cb71c0b3f g_signal_emit_valist (libgobject-2.0.so.0)
#20 0x00007f3cb71c1b0f g_signal_emit (libgobject-2.0.so.0)
#21 0x00007f3cba95a43c clutter_actor_event (libmutter-clutter-0.so)
#22 0x00007f3cba95fa53 _clutter_actor_handle_event (libmutter-clutter-0.so)
#23 0x00007f3cba99ad07 _clutter_process_event (libmutter-clutter-0.so)
#24 0x00007f3cba990639 _clutter_input_device_set_actor (libmutter-clutter-0.so)
#25 0x00007f3cba990c29 _clutter_input_device_update (libmutter-clutter-0.so)
#26 0x00007f3cba99afa5 _clutter_process_event (libmutter-clutter-0.so)
#27 0x00007f3cba9b0e00 _clutter_stage_process_queued_events (libmutter-clutter-0.so)
#28 0x00007f3cba99cbe9 clutter_clock_dispatch (libmutter-clutter-0.so)
#29 0x00007f3cb6ece277 g_main_context_dispatch (libglib-2.0.so.0)
#30 0x00007f3cb6ece618 g_main_context_iterate.isra.25 (libglib-2.0.so.0)
#31 0x00007f3cb6ece932 g_main_loop_run (libglib-2.0.so.0)
#32 0x00007f3cbb8f3bbc meta_run (libmutter-0.so.0)
#33 0x0000564af22604a7 main (gnome-shell)
#34 0x00007f3cb530a5fe __libc_start_main (libc.so.6)
#35 0x0000564af22605ba _start (gnome-shell)
Note, the trace Joachim and I see does *not* look a lot like the trace Chris saw, to me. I think Chris may be seeing yet another crash.
fmuellner says this isn't really directly related to https://bugzilla.redhat.com/show_bug.cgi?id=1443206 - it's just a different crash which we weren't managing to run into before because the other crash happened first. So to be correct, I'll remove the Blocks: for that bug, and propose this bug as a Beta blocker in its own right:
"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."
The desktop is arguably not 'working' if it (apparently quite reliably) crashes shortly after you reach it. Though I'd say this one is a bit less of a slam-dunk blocker, because the g-i-s crash would happen *every time* and cause g-i-s to run again (so you hit the crash again) on your next attempt, whereas this one doesn't seem so obviously repeatable (though #c21 indicates it may recur).
I'm getting a consistent crash in g-i-s with Fedora-Workstation-Live-x86_64-26-20170522.n.1.iso installed in a VM. It happens on every login if I try to go through g-i-s, rather than quitting it, and I get booted to GDM. abrt captures nothing, coredumpctl does, so I filed bug 1455027 with two coredumpctl stack traces for the two different libgweather versions this is crashing with.
Uh, that's the *original* bug, #1443206. -2 never got pushed stable, so that bug has been in nightlies all along. That's exactly how it manifests: g-i-s runs on every login attempt and crashes part way through (unless you change the location privacy setting).
-1 I get a signal 11, and -2 I get a signal 6. If bug 1455027 is now a dup of something, feel free to close it.
To be clear, here, are you saying that for you with -2, GNOME still crashes consistently *part way through g-i-s*, and g-i-s runs again on the next login attempt?
That's not how it was in my test, g-i-s completed successfully and GNOME crashed shortly afterwards...
Correct. With -2 I get a crash in g-i-s upon clicking Next on the 3rd page titled Privacy, and I'm dropped to GDM. If I login again, g-i-s appears, and again it will crash on the 3rd page "Privacy" and drop to GDM. The alternative is to quit g-i-s.
And it looks like it's sometimes a signal 6, sometimes 11. I don't see a pattern, so maybe there's also a race. Sometimes abrt-gui will notify me of a crash next login, sometimes it doesn't. When it does, only after uploading to the retrace server and processing it for 10 minutes does it tell me the backtrace is unusable and a bug can't be filed. So it's not giving dup bug ID but does give a hash which matches the one in bug 1445090.
I found another likely-looking fix upstream:
so I've done a new build, -3:
Can folks please try with that and report how it works for them? Thanks!
FWIW I'm in possibly a weird state in comment 27, in that I had an installation with -1 which did permit me to make a user account and then it crashed, presumably before setting whatever flag that prevents g-i-s from launching again. And then I did a software update which did not include -2 because it was still pending u-t. And then I manually installed -2.
That's a state almost no one will actually be in. What I should test is a system that only ever has -2 upon g-i-s first launch.
-3 fixes it
libgweather-3.24.0-3.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-889e4f475c
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
Discussed at 2017-05-25 Fedora 26 Beta Go/No-Go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting-2/2017-05-25/f26-beta-go-no-go-meeting.2017-05-25-17.00.html . Accepted as a Beta blocker as a violation of "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."
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.