Created attachment 1279786 [details]
File: backtrace

Created attachment 1279787 [details]
File: cgroup

Created attachment 1279788 [details]
File: core_backtrace

Created attachment 1279789 [details]
File: cpuinfo

Created attachment 1279790 [details]
File: dso_list

Created attachment 1279791 [details]
File: environ

Created attachment 1279792 [details]
File: limits

Created attachment 1279793 [details]
File: maps

Created attachment 1279794 [details]
File: open_fds

Created attachment 1279795 [details]
File: proc_pid_status

Created attachment 1279796 [details]
File: var_log_messages

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

Similar problem has been detected:

This crash catalysing by playing and rewinding video in Totem player.

reporter:       libreport-2.9.1
backtrace_rating: 4
cmdline:        /usr/bin/gnome-shell
crash_function: GjsMaybeOwned<JS::Value>::trace
executable:     /usr/bin/gnome-shell
journald_cursor: s=4b44205f8c97439e9d0ad63351d56689;i=32df;b=e87c79a1abbd413a8ec5758409e4acc1;m=39137fca7;t=54ff44be86358;x=12969c06426aa11b
kernel:         4.11.1-300.fc26.x86_64+debug
package:        gnome-shell-3.24.2-1.fc26
reason:         gnome-shell killed by signal 6
rootdir:        /
runlevel:       N 5
type:           CCpp
uid:            1000

Upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=781799

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

Possible duplicates or at least related:
https://bugzilla.redhat.com/show_bug.cgi?id=1451805
https://bugzilla.redhat.com/show_bug.cgi?id=1452453

This issue happens quite often and thus it should be a prioritized bug at least. There is no formal criterium to make it block the final release, but I'd say it qualifies as such anyway.

Proposed as a Blocker and Freeze Exception for 26-final by Fedora user genodeftest using the blocker tracking app because:

 This issue happens quite often and crashes the whole session on the default desktop, GNOME on wayland. This results in data loss. It should be a prioritized bug at least. There is no formal criterium (as far as I know) to make it block the final release, but I'd say it qualifies as such anyway.

Similar problem has been detected:

1. # dnf install gstreamer1-libav
2. Watching your favorite H.264 video with Totem player

reporter:       libreport-2.9.1
backtrace_rating: 4
cmdline:        /usr/bin/gnome-shell
crash_function: GjsMaybeOwned<JS::Value>::trace
executable:     /usr/bin/gnome-shell
journald_cursor: s=4b44205f8c97439e9d0ad63351d56689;i=a827;b=710f3f1a70614f429ad86b7cd6788c00;m=dd95e9b;t=5503c0af6e688;x=99330cfcee549085
kernel:         4.11.1-300.fc26.x86_64+debug
package:        gnome-shell-3.24.2-1.fc26
reason:         gnome-shell killed by signal 6
rootdir:        /
runlevel:       N 5
type:           CCpp
uid:            1000

We really ought to have a blocker criterion that covers *commonly-encountered* full desktop crashes. I admittedly can't find one either, but I bet the QA folks will be able to think of one that applies.

These are possibly duplicates:

https://bugzilla.redhat.com/buglist.cgi?quicksearch=GjsMaybeOwned&list_id=7404884

Similar problem has been detected:

gnome-shell session ended when I watching movie in Totem player

reporter:       libreport-2.9.1
backtrace_rating: 4
cmdline:        /usr/bin/gnome-shell
crash_function: GjsMaybeOwned<JS::Value>::trace
executable:     /usr/bin/gnome-shell
journald_cursor: s=a904c01ca9734563afe62370c5f48ca4;i=d0c5;b=fb9011e634a64bc6805cc45d242dc6d5;m=14f4ae6fdd;t=54fbe080aa62d;x=dc6ff67540b02f46
kernel:         4.11.0-2.fc26.x86_64+debug
package:        gnome-shell-3.24.2-1.fc26
reason:         gnome-shell killed by signal 6
rootdir:        /
runlevel:       N 5
type:           CCpp
uid:            1000

Similar problem has been detected:

Crashed when played video in Totem player

reporter:       libreport-2.9.1
backtrace_rating: 4
cmdline:        /usr/bin/gnome-shell
crash_function: GjsMaybeOwned<JS::Value>::trace
executable:     /usr/bin/gnome-shell
journald_cursor: s=4b44205f8c97439e9d0ad63351d56689;i=28f25;b=d014ffaf9e2647fc8cdbdd9067e324cb;m=2aa4672c73;t=5511594ce5825;x=147e751b68bab5f9
kernel:         4.11.3-300.fc26.x86_64+debug
package:        gnome-shell-3.24.2-1.fc26
reason:         gnome-shell killed by signal 6
rootdir:        /
runlevel:       N 5
type:           CCpp
uid:            1000

How about https://bugzilla.redhat.com/show_bug.cgi?id=1450639 ? the trace is different, but the descriptions sound very similar - crash when playing videos with Totem, often with libav...

Discussed at 2017-06-05 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-06-05/f26-blocker-review.2017-06-05-16.01.html . Notwithstanding the question of exactly what is a dupe of what, we agreed that the general issue - many people seem to be able to crash GNOME Shell frequently just by playing a video in Totem - counts as a blocker, with reference to two criteria:

"All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test." - playing a video is pretty 'basic functionality' in Totem, and it shouldn't crash Totem, let alone GNOME.

"All known bugs that can cause corruption of user data must be fixed or documented at Common F26 bugs." - any GNOME Shell crash under Wayland can be argued to fall under this criterion, as GNOME cannot currently recover from Shell crashes gracefully as it does under X11; it just immediately kills the session and all running apps.

This issue happens way less often (or even never) when using GNOME/Xorg instead of GNOME/Wayland.

For anyone running into this bug, I can recommend using GNOME/Xorg as a workaround. In case this bug cannot be fixed soon, this could also be a fallback strategy for the Fedora 26 Final release.

This happens during javascript garbage collection, so either in gjs or mozjs38.

The upstream bug report https://bugzilla.gnome.org/show_bug.cgi?id=781799 has some patches attached. Can you please provide a build with these patches applied so we can test? If you don't want to push the build to updates-testing, a koji link should be sufficient.

gjs-1.48.3-3.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-0ee2da9169

gjs-1.48.3-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-0ee2da9169

gjs-1.48.4-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-f93990025d

gjs-1.48.4-1.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-f93990025d

gjs-1.48.4-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

I'm seeing a very similar problem on gjs-1.48.5:

Aug 07 15:43:56 ravenholm systemd-coredump[15151]: Process 4840 (gnome-shell) of user 1000 dumped core.
                                                   
                                                   Stack trace of thread 4840:
                                                   #0  0x00007f0bfec27085 n/a (libgjs.so.0)
                                                   #1  0x00007f0bf746cc27 g_idle_dispatch (libglib-2.0.so.0)
                                                   #2  0x00007f0bf7470247 g_main_context_dispatch (libglib-2.0.so.0)
                                                   #3  0x00007f0bf74705e8 g_main_context_iterate.isra.25 (libglib-2.0.so.0)
                                                   #4  0x00007f0bf7470902 g_main_loop_run (libglib-2.0.so.0)
                                                   #5  0x00007f0bfbe8daec meta_run (libmutter-0.so.0)
                                                   #6  0x00005630b29914a7 main (gnome-shell)
                                                   #7  0x00007f0bf58aa4da __libc_start_main (libc.so.6)
                                                   #8  0x00005630b29915ba _start (gnome-shell)

(In reply to Chris Coughlan from comment #31)
> I'm seeing a very similar problem on gjs-1.48.5:

How do you even know your problem is similar? Please install debug symbols before posting any such backtraces. Without debug symbols they are useless.

Anyway, gjs-1.48.6 has been released a week ago, you should try installing the update first.