Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1442631 - crash on login following software update; (gnome-shell) of user 1000 dumped core
Summary: crash on login following software update; (gnome-shell) of user 1000 dumped core
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-shell
Version: 26
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Owen Taylor
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F26FinalBlocker
TreeView+ depends on / blocked
Reported: 2017-04-16 19:55 UTC by Chris Murphy
Modified: 2017-06-19 16:43 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-06-14 19:07:21 UTC
Type: Bug

Attachments (Terms of Use)
journal.log (deleted)
2017-04-16 19:55 UTC, Chris Murphy
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1438026 0 unspecified CLOSED GNOME crashes several times a day due to bug in driver 2021-02-22 00:41:40 UTC

Internal Links: 1438026

Description Chris Murphy 2017-04-16 19:55:07 UTC
Created attachment 1271899 [details]

Description of problem:

Following a successful gnome-software update and reboot (the reboot following the update), I login, and shortly after the desktop draws and I see a notification for updates applied, it all goes away and I get a login window.

Version-Release number of selected component (if applicable):

How reproducible:
One time so far.

Steps to Reproduce:
1. Login

Actual results:


Expected results:

No crash

Additional info:

Comment 1 Chris Murphy 2017-04-16 19:59:49 UTC
Coredump file is too large for bugzilla. It's here:

       Storage: /var/lib/systemd/coredump/core.gnome-shell.1000.800ef42f9db94f2cb363157aae7a87c1.1729.1492371797000000.lz4
       Message: Process 1729 (gnome-shell) of user 1000 dumped core.
                Stack trace of thread 1729:
                #0  0x00007f6795df27bb raise (
                #1  0x00007f6795df45d1 abort (
                #2  0x00007f6795e389c9 __libc_message (
                #3  0x00007f6795e437e9 _int_free (
                #4  0x00007f6795e490ee __libc_free (
                #5  0x00007f67979a5b0e g_free (
                #6  0x00007f6737defdc1 gweather_location_unref (
                #7  0x00007f6737de5e91 gweather_info_set_location_internal (
                #8  0x00007f6737dea1ad gweather_info_set_location (
                #9  0x00007f6794a6bbde ffi_call_unix64 (
                #10 0x00007f6794a6b54f ffi_call (
                #11 0x00007f679f17001c n/a (
                #12 0x00007f679f1717c6 n/a (
                #13 0x00007f679458b6a8 _ZN2js6InvokeEP9JSContextN2JS8CallArgsENS_14MaybeConstructE (
                #14 0x00007f67945814cd _ZL9InterpretP9JSContextRN2js8RunStateE (
                #15 0x00007f679458b324 _ZN2js9RunScriptEP9JSContextRNS_8RunStateE (
                #16 0x00007f679458b614 _ZN2js6InvokeEP9JSContextN2JS8CallArgsENS_14MaybeConstructE (
                #17 0x00007f679458c243 _ZN2js6InvokeEP9JSContextRKN2JS5ValueES5_jPS4_NS2_13MutableHandleIS3_EE (
                #18 0x00007f67947e4bfb _ZN2js3jit14InvokeFunctionEP9JSContextN2JS6HandleIP8JSObjectEEjPNS3_5ValueES9_ (
                #19 0x00007f67a07da134 n/a (n/a)

Comment 2 Chris Murphy 2017-04-19 23:49:21 UTC
I'm hitting this now pretty much daily on two different i915 computers.


model name	: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 520 [8086:1916] (rev 07) (prog-if 00 [VGA controller])


model name	: Intel(R) Core(TM) i7-2820QM CPU @ 2.30GHz
00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) (prog-if 00 [VGA controller])

Comment 3 Chris Murphy 2017-04-20 00:05:38 UTC
Likely a dup of bug 1443206 but in case it's not (it does not happen at login, it's happening well after login and is not reproducible but does happen daily)

Proposing as a final release blocker:

All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use. 

and because I'm losing data in the login environment when this happens:

All known bugs that can cause corruption of user data must be fixed or documented at Common F26 bugs.

Comment 4 Chris Murphy 2017-04-20 00:14:34 UTC
I got the same crash and call trace when launching the Weather app. 2nd launch is OK but then it crashes when searching for my town. Then 3rd launch its OK, finds my town and shows the weather, when I go to Places and turn off auto location, it crashes again. 4th launch I can toggle autolocation and it doesn't crash. So...yeah.

It's pushing the limit of being a beta blocker:

No part of any release-blocking desktop's panel (or equivalent) configuration may crash on startup or be entirely non-functional.

Comment 5 Chris Murphy 2017-04-20 00:17:26 UTC
I think the "random" trigger is because gnome-shell date/time, click on that to see notifications and calendar, under the calendar is local weather and a world clock. I wonder if this is a weather update or a location update that's triggering this.

Comment 6 Geoffrey Marr 2017-04-24 19:19:16 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:

"No part of any release-blocking desktop's panel (or equivalent) configuration may crash on startup or be entirely non-functional."


Comment 7 Michael Catanzaro 2017-04-30 19:30:35 UTC
So can you reproduce this with libgweather-3.24.0-2.fc26? I would be pretty surprised if this is not a dup of bug #1443206.

Comment 8 Chris Murphy 2017-04-30 20:27:20 UTC
Weirdly it hasn't happened in a while even with all same versions as before


The one thing different is the kernel, I've been on rc7 and rc8 since this was reported.

Comment 9 Thomas Vollstädt 2017-06-12 10:18:14 UTC
My gnome-shell also crashes multiple times a day. I'm on a Thinkpad X1 Yoga with Intel HD 520 (Skylake).

gnome-shell.x86_64                      3.24.2-1.fc26
mutter.x86_64                           3.24.2-1.fc26 
kernel.x86_64                           4.11.3-302.fc26

The crashes are unreproducible, seems to happen randomly (also happened while on the noficiation panel, but doesnt seem to relate). Output of coredumpctl:

Thu 2017-06-08 11:09:05 CEST   1619  1000  1000  11 missing   /usr/bin/gnome-shell
Thu 2017-06-08 14:19:08 CEST   1605  1000  1000  11 missing   /usr/bin/gnome-shell
Fri 2017-06-09 01:19:57 CEST   1555  1000  1000   6 missing   /usr/bin/gnome-shell
Fri 2017-06-09 13:44:21 CEST   6717  1000  1000  11 present   /usr/bin/gnome-shell
Sat 2017-06-10 22:44:20 CEST  10894  1000  1000  11 present   /usr/bin/gnome-shell
Sun 2017-06-11 00:39:07 CEST   5716  1000  1000  11 present   /usr/bin/gnome-shell
Sun 2017-06-11 17:16:01 CEST  23927  1000  1000   6 present   /usr/bin/gnome-shell
Mon 2017-06-12 10:15:05 CEST  14471  1000  1000   6 present   /usr/bin/gnome-shell
Mon 2017-06-12 11:14:09 CEST   3457  1000  1000   6 present   /usr/bin/gnome-shell

... and so on.

It really happens very often, so I would consider this a blocker for the release.

Is there a way to securely submit core dumps? It seems likely that a dump of gnome-shell contains sensitive information.

Stacktrace of latest crash:

Comment 10 Adam Williamson 2017-06-14 18:47:24 UTC
Thomas, at a quick glance, your trace looks nothing at all like Chris'. Can you please file a new bug? Thanks. There isn't an automatic way to strip sensitive data from core dumps, but a good stack trace ought to be sufficient.

Chris, have you run into this again since we last asked? If not, I think we can go ahead and close this one.

Comment 11 Chris Murphy 2017-06-14 18:53:42 UTC

Comment 12 Adam Williamson 2017-06-14 19:07:21 UTC
Let's just go ahead and close it, then.

Comment 13 Thomas Vollstädt 2017-06-19 16:43:45 UTC
For reference, new bug is here:

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