Coredump file is too large for bugzilla. It's here:
https://drive.google.com/open?id=0B_2Asp8DGjJ9OVVwendqYkQ0MDA


       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 (libc.so.6)
                #1  0x00007f6795df45d1 abort (libc.so.6)
                #2  0x00007f6795e389c9 __libc_message (libc.so.6)
                #3  0x00007f6795e437e9 _int_free (libc.so.6)
                #4  0x00007f6795e490ee __libc_free (libc.so.6)
                #5  0x00007f67979a5b0e g_free (libglib-2.0.so.0)
                #6  0x00007f6737defdc1 gweather_location_unref (libgweather-3.so.6)
                #7  0x00007f6737de5e91 gweather_info_set_location_internal (libgweather-3.so.6)
                #8  0x00007f6737dea1ad gweather_info_set_location (libgweather-3.so.6)
                #9  0x00007f6794a6bbde ffi_call_unix64 (libffi.so.6)
                #10 0x00007f6794a6b54f ffi_call (libffi.so.6)
                #11 0x00007f679f17001c n/a (libgjs.so.0)
                #12 0x00007f679f1717c6 n/a (libgjs.so.0)
                #13 0x00007f679458b6a8 _ZN2js6InvokeEP9JSContextN2JS8CallArgsENS_14MaybeConstructE (libmozjs-38.so)
                #14 0x00007f67945814cd _ZL9InterpretP9JSContextRN2js8RunStateE (libmozjs-38.so)
                #15 0x00007f679458b324 _ZN2js9RunScriptEP9JSContextRNS_8RunStateE (libmozjs-38.so)
                #16 0x00007f679458b614 _ZN2js6InvokeEP9JSContextN2JS8CallArgsENS_14MaybeConstructE (libmozjs-38.so)
                #17 0x00007f679458c243 _ZN2js6InvokeEP9JSContextRKN2JS5ValueES5_jPS4_NS2_13MutableHandleIS3_EE (libmozjs-38.so)
                #18 0x00007f67947e4bfb _ZN2js3jit14InvokeFunctionEP9JSContextN2JS6HandleIP8JSObjectEEjPNS3_5ValueES9_ (libmozjs-38.so)
                #19 0x00007f67a07da134 n/a (n/a)

I'm hitting this now pretty much daily on two different i915 computers.

kernel-4.11.0-0.rc6.git0.1.fc26.x86_64

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


and

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

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.

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.

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.

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

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

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.

Weirdly it hasn't happened in a while even with all same versions as before

libgweather-3.24.0-1.fc26.x86_64
mutter-3.24.1-1.fc26.x86_64
gnome-shell-3.24.1-1.fc26.x86_64

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

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: https://nopaste.linux-dev.org/?1158925

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.

No.

Let's just go ahead and close it, then.

For reference, new bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=1462839