I am almost certain that the RedHat bug is a red herring.

Could you please make sure to try this with GJS 1.48.6 and not just with the patch applied to 1.48.3? It may be a duplicate of the crashes fixed in 1.48.4 or 1.48.5.

Would you be able to get a stack trace with debug symbols?

Created attachment 357147 [details]
Core dump

$ rpm -qa gjs*
gjs-debuginfo-1.48.6-1.fc26.x86_64
gjs-1.48.6-1.fc26.x86_64

https://vondruch.fedorapeople.org/dump.xz

And this is the backtrace from ABRT, which is reported as duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1456293


~~~
[New LWP 3977]
[New LWP 3979]
[New LWP 3978]
[New LWP 4117]
[New LWP 3981]
[New LWP 4121]
[New LWP 4119]
[New LWP 4120]
[New LWP 4123]
[New LWP 4118]
[New LWP 4125]
[New LWP 4124]
[New LWP 4122]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/bin/gnome-shell'.
Program terminated with signal SIGSEGV, Segmentation fault.

+ Trace 237783

From                To                  Syms Read   Shared Object Library
0x00007f1ad27bfd90  0x00007f1ad27d94fe  Yes         /usr/lib64/gnome-shell/libgnome-shell.so
0x00007f1ad24376b0  0x00007f1ad2521c52  Yes         /lib64/libgio-2.0.so.0
0x00007f1ad21b6730  0x00007f1ad21e95a5  Yes         /lib64/libgobject-2.0.so.0
0x00007f1ad1eb2f00  0x00007f1ad1f2b208  Yes         /lib64/libglib-2.0.so.0
0x00007f1ad161dea0  0x00007f1ad19606b9  Yes         /lib64/libgtk-3.so.0
0x00007f1ad13903d0  0x00007f1ad13953fe  Yes         /lib64/libpangocairo-1.0.so.0
0x00007f1ad1166b70  0x00007f1ad117ac38  Yes         /lib64/libatk-bridge-2.0.so.0
0x00007f1ad0eb89b0  0x00007f1ad0f06853  Yes         /lib64/libgjs.so.0
0x00007f1ad0b715e0  0x00007f1ad0c31343  Yes         /usr/lib64/mutter/libmutter-clutter-0.so
0x00007f1ad09346b0  0x00007f1ad0936f7a  Yes         /usr/lib64/mutter/libmutter-cogl-pango-0.so
0x00007f1ad0703440  0x00007f1ad072209c  Yes         /lib64/libgirepository-1.0.so.1
0x00007f1ad03f7420  0x00007f1ad049cd1a  Yes         /lib64/libmutter-0.so.0
0x00007f1ad018cb00  0x00007f1ad019b251  Yes         /lib64/libpthread.so.0
0x00007f1acfdc2790  0x00007f1acff31b2c  Yes         /lib64/libc.so.6
0x00007f1acfb99a70  0x00007f1acfb9da98  Yes         /usr/lib64/gnome-shell/libgnome-shell-menu.so
0x00007f1acf959d70  0x00007f1acf982989  Yes         /usr/lib64/gnome-shell/libst-1.0.so
0x00007f1acf67c050  0x00007f1acf6f0897  Yes         /lib64/libgdk-3.so.0
0x00007f1acf33dc40  0x00007f1acf40cbd6  Yes         /lib64/libcairo.so.2
0x00007f1acf10a240  0x00007f1acf11fe89  Yes         /lib64/libgdk_pixbuf-2.0.so.0
0x00007f1acee6da40  0x00007f1aceece1ba  Yes         /usr/lib64/mutter/libmutter-cogl-0.so
0x00007f1aceb33d50  0x00007f1acebbab98  Yes         /lib64/libX11.so.6
0x00007f1ace911480  0x00007f1ace913716  Yes         /lib64/libXfixes.so.3
0x00007f1ace708ea0  0x00007f1ace70c2fe  Yes         /lib64/libstartup-notification-1.so.0
0x00007f1ace4f6df0  0x00007f1ace50033a  Yes         /lib64/libcanberra.so.0
0x00007f1ace2f0ae0  0x00007f1ace2f20ae  Yes         /lib64/libcanberra-gtk3.so.0
0x00007f1ace0e89f0  0x00007f1ace0eb6cc  Yes         /lib64/libpolkit-agent-1.so.0
0x00007f1acdecf070  0x00007f1acdeda8d2  Yes         /lib64/libpolkit-gobject-1.so.0
0x00007f1acdc514d0  0x00007f1acdc97211  Yes         /lib64/libgcr-base-3.so.1
0x00007f1acd9b4380  0x00007f1acda0db04  No          /lib64/libsystemd.so.0
0x00007f1acd772530  0x00007f1acd792756  Yes         /lib64/libnm-glib.so.4
0x00007f1acd5180c0  0x00007f1acd548b52  Yes         /lib64/libnm-util.so.2
0x00007f1acd2df140  0x00007f1acd2f3971  Yes         /lib64/libdbus-glib-1.so.2
0x00007f1acd0913f0  0x00007f1acd0bc006  Yes         /lib64/libsecret-1.so.0
0x00007f1accd7a410  0x00007f1acce1f73f  Yes         /lib64/libgstreamer-1.0.so.0
0x00007f1accaf6880  0x00007f1accb31b9d  Yes         /lib64/libgstbase-1.0.so.0
0x00007f1acc8e3680  0x00007f1acc8e7e3a  Yes         /lib64/libffi.so.6
0x00007f1acc6df0f0  0x00007f1acc6dffe6  Yes         /lib64/libgmodule-2.0.so.0
0x00007f1acc4dae50  0x00007f1acc4dbb7e  Yes         /lib64/libdl.so.2
0x00007f1acc268540  0x00007f1acc2ba32d  Yes         /lib64/libpcre.so.1
0x00007f1acc052260  0x00007f1acc05f09f  Yes         /lib64/libz.so.1
0x00007f1acbe2da00  0x00007f1acbe44a7f  Yes         /lib64/libselinux.so.1
0x00007f1acbc10830  0x00007f1acbc1fdb2  Yes         /lib64/libresolv.so.2
0x00007f1acb9c4d30  0x00007f1acb9f7a78  Yes         /lib64/libmount.so.1
0x00007f1acb7a4ac0  0x00007f1acb7b4de5  Yes         /lib64/libgcc_s.so.1
0x00007f1acb594070  0x00007f1acb59e987  Yes         /lib64/libXi.so.6
0x00007f1acb38c480  0x00007f1acb38d3f9  Yes         /lib64/libcairo-gobject.so.2
0x00007f1acb16dbb0  0x00007f1acb17a482  Yes         /lib64/libatk-1.0.so.0
0x00007f1acaec3ad0  0x00007f1acaf08bb1  Yes         /lib64/libepoxy.so.0
0x00007f1acac6d900  0x00007f1acac75ead  Yes         /lib64/libpangoft2-1.0.so.0
0x00007f1acaa287f0  0x00007f1acaa47506  Yes         /lib64/libpango-1.0.so.0
0x00007f1aca7dedd0  0x00007f1aca7fe76a  Yes         /lib64/libfontconfig.so.1
0x00007f1aca48a880  0x00007f1aca533985  Yes         /lib64/libm.so.6
0x00007f1aca27ad90  0x00007f1aca27e7f3  Yes         /lib64/libthai.so.0
0x00007f1aca077610  0x00007f1aca07776a  Yes         /lib64/libgthread-2.0.so.0
0x00007f1ac9de6a70  0x00007f1ac9e3c428  Yes         /lib64/libharfbuzz.so.0
0x00007f1ac9b36170  0x00007f1ac9badf24  Yes         /lib64/libfreetype.so.6
0x00007f1ac9907fe0  0x00007f1ac9919908  Yes         /lib64/libatspi.so.0
0x00007f1ac96b6900  0x00007f1ac96e2121  Yes (*)     /lib64/libdbus-1.so.3
0x00007f1ac9471a40  0x00007f1ac9495295  Yes         /lib64/libreadline.so.7
0x00007f1ac8e22c50  0x00007f1ac930b0e2  Yes         /lib64/libmozjs-38.so
0x00007f1ac8b4b4f0  0x00007f1ac8b5550f  Yes         /lib64/libXext.so.6
0x00007f1ac884c130  0x00007f1ac88fbe58  Yes         /lib64/libstdc++.so.6
0x00007f1ac85a25d0  0x00007f1ac85b56bd  Yes         /lib64/libjson-glib-1.0.so.0
0x00007f1ac8398640  0x00007f1ac8398806  Yes         /lib64/libwayland-egl.so.1
0x00007f1ac818e380  0x00007f1ac8192cff  No          /lib64/libwayland-client.so.0
0x00007f1ac7f84330  0x00007f1ac7f86d2b  Yes         /lib64/libXtst.so.6
0x00007f1ac7d68950  0x00007f1ac7d7a893  No          /lib64/libudev.so.1
0x00007f1ac7b386d0  0x00007f1ac7b5593a  Yes         /lib64/libinput.so.10
0x00007f1ac78f4240  0x00007f1ac790ec3a  Yes         /lib64/libxkbcommon.so.0
0x00007f1ac76e10f0  0x00007f1ac76ea922  Yes         /usr/lib64/mutter/libmutter-cogl-path-0.so
0x00007f1ac74d3a30  0x00007f1ac74d90f5  Yes         /lib64/libgbm.so.1
0x00007f1ac72c3b10  0x00007f1ac72cc360  Yes         /lib64/libdrm.so.2
0x00007f1ac70b3790  0x00007f1ac70b99af  No          /lib64/libwayland-server.so.0
0x00007f1ac6e9cd70  0x00007f1ac6ea7147  Yes         /lib64/libEGL.so.1
0x00007f1ac6c97b20  0x00007f1ac6c9840b  Yes         /lib64/libXdamage.so.1
0x00007f1ac6a94bd0  0x00007f1ac6a955a5  Yes         /lib64/libXcomposite.so.1
0x00007f1ac688aba0  0x00007f1ac6890b85  Yes         /lib64/libXrandr.so.2
0x00007f1ac666b960  0x00007f1ac667cdc6  Yes         /lib64/libupower-glib.so.3
0x00007f1ac64370b0  0x00007f1ac6450a6b  Yes         /lib64/libgnome-desktop-3.so.12
0x00007f1ac621f730  0x00007f1ac6224180  Yes         /lib64/libXcursor.so.1
0x00007f1ac5ffb850  0x00007f1ac6014813  Yes         /lib64/libxkbfile.so.1
0x00007f1ac5df1560  0x00007f1ac5df3f03  Yes         /lib64/libxkbcommon-x11.so.0
0x00007f1ac5be69a0  0x00007f1ac5bec935  Yes         /lib64/libXrender.so.1
0x00007f1ac59e3540  0x00007f1ac59e363b  Yes         /lib64/libX11-xcb.so.1
0x00007f1ac57c66a0  0x00007f1ac57d83f5  Yes         /lib64/libxcb.so.1
0x00007f1ac55b1770  0x00007f1ac55b5db9  Yes         /lib64/libxcb-randr.so.0
0x00007f1ac53a85e0  0x00007f1ac53a90a5  Yes         /lib64/libxcb-res.so.0
0x00007f1ac51a0a60  0x00007f1ac51a4aa0  Yes         /lib64/libSM.so.6
0x00007f1ac4f87b00  0x00007f1ac4f9568e  Yes         /lib64/libICE.so.6
0x00007f1ac4d80a90  0x00007f1ac4d81405  Yes         /lib64/libXinerama.so.1
0x00007f1ac4b795a0  0x00007f1ac4b7c6f2  Yes         /lib64/libgudev-1.0.so.0
0x00007f1ad2bf0d50  0x00007f1ad2c10300  Yes         /lib64/ld-linux-x86-64.so.2
0x00007f1ac4943a90  0x00007f1ac4961e15  Yes         /lib64/libcroco-0.6.so.3
0x00007f1ac47341f0  0x00007f1ac4735cff  No          /lib64/libwayland-cursor.so.0
0x00007f1ac452d1a0  0x00007f1ac45306b6  Yes         /lib64/librt.so.1
0x00007f1ac4290220  0x00007f1ac431283d  Yes         /lib64/libpixman-1.so.0
0x00007f1ac40584c0  0x00007f1ac4079ef8  Yes         /lib64/libpng16.so.16
0x00007f1ac3e4fd30  0x00007f1ac3e50823  Yes         /lib64/libxcb-shm.so.0
0x00007f1ac3c45f80  0x00007f1ac3c4a898  Yes         /lib64/libxcb-render.so.0
0x00007f1ac39f5300  0x00007f1ac39f863f  Yes         /lib64/libGL.so.1
0x00007f1ac37b1420  0x00007f1ac37b217c  Yes         /lib64/libxcb-util.so.1
0x00007f1ac35a7d50  0x00007f1ac35ac12c  Yes         /lib64/libvorbisfile.so.3
0x00007f1ac3393250  0x00007f1ac339ec52  Yes         /lib64/libtdb.so.1
0x00007f1ac31883a0  0x00007f1ac318c57c  Yes         /lib64/libltdl.so.7
0x00007f1ac2f56fa0  0x00007f1ac2f73843  Yes         /lib64/libexpat.so.1
0x00007f1ac2d25ca0  0x00007f1ac2d438b7  Yes         /lib64/libgck-1.so.0
0x00007f1ac2a18500  0x00007f1ac2ad87b8  Yes         /lib64/libgcrypt.so.20
0x00007f1ac27fba70  0x00007f1ac2805aa8  Yes         /lib64/libgpg-error.so.0
0x00007f1ac24f5450  0x00007f1ac2587c36  Yes         /lib64/libp11-kit.so.0
0x00007f1ac22a6df0  0x00007f1ac22bd7c2  Yes         /lib64/liblzma.so.5
0x00007f1ac2092330  0x00007f1ac20a08c1  Yes         /lib64/liblz4.so.1
0x00007f1ac1e8c3f0  0x00007f1ac1e8d9f3  Yes         /lib64/libuuid.so.1
0x00007f1ac1c49e70  0x00007f1ac1c7552f  Yes         /lib64/libssl3.so
0x00007f1ac1a20200  0x00007f1ac1a34ae7  Yes         /lib64/libsmime3.so
0x00007f1ac1707a30  0x00007f1ac17d890c  Yes         /lib64/libnss3.so
0x00007f1ac14ca290  0x00007f1ac14da268  Yes         /lib64/libnssutil3.so
0x00007f1ac12bae70  0x00007f1ac12bbbb8  Yes         /lib64/libplds4.so
0x00007f1ac10b6460  0x00007f1ac10b7b01  Yes         /lib64/libplc4.so
0x00007f1ac0e83bd0  0x00007f1ac0ea417f  Yes         /lib64/libnspr4.so
0x00007f1ac0c36720  0x00007f1ac0c627a8  Yes         /lib64/libblkid.so.1
0x00007f1ac0a27260  0x00007f1ac0a2a3f0  Yes         /lib64/libdatrie.so.1
0x00007f1ac07fc640  0x00007f1ac081dce8  Yes         /lib64/libgraphite2.so.3
0x00007f1ac05eb570  0x00007f1ac05f75e2  Yes         /lib64/libbz2.so.1
0x00007f1ac03cbf20  0x00007f1ac03d8d58  Yes (*)     /lib64/libtinfo.so.6
0x00007f1ac0006050  0x00007f1ac013c56b  Yes         /lib64/libicui18n.so.57
0x00007f1abfbfa7a0  0x00007f1abfcbe08b  Yes         /lib64/libicuuc.so.57
0x00007f1abe121510  0x00007f1abe121610  Yes (*)     /lib64/libicudata.so.57
0x00007f1abdf1be80  0x00007f1abdf1e1e0  Yes         /lib64/libmtdev.so.1
0x00007f1abdd0b370  0x00007f1abdd10535  Yes         /lib64/libevdev.so.2
0x00007f1abdaf9e20  0x00007f1abdafdca6  Yes         /lib64/libwacom.so.2
0x00007f1abd87fa90  0x00007f1abd882917  Yes         /lib64/libGLdispatch.so.0
0x00007f1abd62dbc0  0x00007f1abd63a015  Yes         /usr/lib64/libxcb-xkb.so.1
0x00007f1abd420d40  0x00007f1abd421a38  Yes         /lib64/libXau.so.6
0x00007f1abd0e5fd0  0x00007f1abd1cad3e  Yes         /lib64/libxml2.so.2
0x00007f1abce88da0  0x00007f1abce928e5  Yes         /lib64/libGLX.so.0
0x00007f1abcc5d320  0x00007f1abcc73ab2  Yes         /usr/lib64/libvorbis.so.0
0x00007f1abca54870  0x00007f1abca56c45  Yes         /usr/lib64/libogg.so.0
0x00007f1abc81bc40  0x00007f1abc8217f8  Yes         /lib64/libcrypt.so.1
0x00007f1abc61aab0  0x00007f1abc61b1f0  Yes         /lib64/libfreebl3.so
0x00007f1ab403e750  0x00007f1ab40437ee  Yes         /usr/lib64/gio/modules/libdconfsettings.so
0x00007f1aa75cf650  0x00007f1aa75ebe58  Yes         /lib64/libEGL_mesa.so.0
0x00007f1aa73c3850  0x00007f1aa73c4955  Yes         /lib64/libxcb-dri2.so.0
0x00007f1aa71bfc90  0x00007f1aa71c0423  Yes         /lib64/libxcb-dri3.so.0
0x00007f1aa6fb9b90  0x00007f1aa6fbc0a5  Yes         /lib64/libxcb-xfixes.so.0
0x00007f1aa6db4d20  0x00007f1aa6db5586  Yes         /lib64/libxcb-present.so.0
0x00007f1aa6baf1b0  0x00007f1aa6bb1202  Yes         /lib64/libxcb-sync.so.1
0x00007f1aa69ab8a0  0x00007f1aa69abb6c  Yes         /lib64/libxshmfence.so.1
0x00007f1aa6785680  0x00007f1aa6790b7b  Yes         /lib64/libglapi.so.0
0x00007f1aa5e351b0  0x00007f1aa63a5008  Yes         /usr/lib64/dri/i965_dri.so
0x00007f1aa5ba9e10  0x00007f1aa5bbeea2  Yes         /lib64/libdrm_intel.so.1
0x00007f1aa59a07f0  0x00007f1aa59a472d  Yes         /lib64/libdrm_nouveau.so.2
0x00007f1aa5794650  0x00007f1aa579bf92  Yes         /lib64/libdrm_radeon.so.1
0x00007f1aa558c0d0  0x00007f1aa5590375  Yes         /lib64/libpciaccess.so.0
0x00007f1aa5361080  0x00007f1aa537bad6  Yes         /usr/lib64/gio/modules/libgvfsdbus.so
0x00007f1aa512ad80  0x00007f1aa5141d76  Yes         /usr/lib64/gvfs/libgvfscommon.so
0x00007f1aa4f15e70  0x00007f1aa4f1682a  Yes         /lib64/libutil.so.1
0x00007f1aa4d0ee70  0x00007f1aa4d11fea  Yes         /usr/lib64/libcanberra-0.30/libcanberra-pulse.so
0x00007f1aa4ac8d20  0x00007f1aa4af5852  Yes (*)     /lib64/libpulse.so.0
0x00007f1aa484e850  0x00007f1aa48932b8  Yes (*)     /usr/lib64/pulseaudio/libpulsecommon-10.99.so
0x00007f1aa4634480  0x00007f1aa4635d87  Yes         /lib64/libcap.so.2
0x00007f1aa442b400  0x00007f1aa442f0c7  Yes         /lib64/libwrap.so.0
0x00007f1aa41be550  0x00007f1aa4206885  Yes         /lib64/libsndfile.so.1
0x00007f1a9fdfb1c0  0x00007f1a9fdfd7b8  Yes         /lib64/libasyncns.so.0
0x00007f1a9fbe4040  0x00007f1a9fbf1927  Yes         /lib64/libnsl.so.1
0x00007f1a9f9d52a0  0x00007f1a9f9dd76a  Yes         /lib64/libgsm.so.1
0x00007f1a9f783ab0  0x00007f1a9f7c84eb  Yes         /lib64/libFLAC.so.8
0x00007f1a9f4e5a80  0x00007f1a9f4e821c  Yes         /lib64/libvorbisenc.so.2
0x00007f1a993e6dc0  0x00007f1a993f4395  Yes         /lib64/libcaribou.so.0
0x00007f1a991ca120  0x00007f1a991d527b  Yes         /lib64/libxklavier.so.16
0x00007f1a98f0ae40  0x00007f1a98f82ada  Yes         /lib64/libgee-0.8.so.2
0x00007f1a986e5d20  0x00007f1a986f5412  Yes         /lib64/libgweather-3.so.6
0x00007f1a98435e00  0x00007f1a9847d538  Yes         /lib64/libsoup-2.4.so.1
0x00007f1a981d8f70  0x00007f1a981e2e2f  Yes         /lib64/libgeocode-glib.so.0
0x00007f1a87d31d60  0x00007f1a87dd75e0  No          /lib64/libsqlite3.so.0
0x00007f1a87ae4020  0x00007f1a87b164ff  No          /lib64/libgssapi_krb5.so.2
0x00007f1a87816870  0x00007f1a8787deb8  Yes         /lib64/libkrb5.so.3
0x00007f1a875c2840  0x00007f1a875e10c0  Yes         /lib64/libk5crypto.so.3
0x00007f1a873bb380  0x00007f1a873bbf4a  Yes         /lib64/libcom_err.so.2
0x00007f1a871ae6c0  0x00007f1a871b5601  No          /lib64/libkrb5support.so.0
0x00007f1a86fa84b0  0x00007f1a86fa919c  Yes         /lib64/libkeyutils.so.1
0x00007f1a86d4e7c0  0x00007f1a86d756ba  Yes (*)     /lib64/libibus-1.0.so.5
0x00007f1a86b041b0  0x00007f1a86b2dd26  Yes         /lib64/libsoftokn3.so
0x00007f1a868812c0  0x00007f1a868d976d  Yes         /lib64/libfreeblpriv3.so
0x00007f1a86648840  0x00007f1a866668b2  Yes         /lib64/libgnome-bluetooth.so.13
0x00007f1a86434510  0x00007f1a864368bb  Yes         /lib64/libnotify.so.4
0x00007f1a8621b860  0x00007f1a86228851  Yes         /usr/lib64/gnome-shell/libgvc.so
0x00007f1a86010ca0  0x00007f1a86012533  Yes (*)     /lib64/libpulse-mainloop-glib.so.0
0x00007f1a85ddd300  0x00007f1a85df89d6  Yes         /lib64/libaccountsservice.so.0
0x00007f1a85bc2530  0x00007f1a85bc7148  No          /lib64/libnss_sss.so.2
0x00007f1a851a36e0  0x00007f1a851b1426  Yes         /lib64/libgdm.so.1
0x00007f1a84dba5d0  0x00007f1a84ed4c96  Yes         /lib64/libtelepathy-glib.so.0
0x00007f1a84b4edc0  0x00007f1a84b5a856  Yes         /usr/lib64/gio/modules/libgioremote-volume-monitor.so
0x00007f1a849328c0  0x00007f1a8493f986  Yes         /usr/lib64/gio/modules/libgiognutls.so
0x00007f1a845e9440  0x00007f1a846d2f4a  Yes         /lib64/libgnutls.so.30
0x00007f1a843a16a0  0x00007f1a843a5063  Yes         /lib64/libidn2.so.0
0x00007f1a8403e7a0  0x00007f1a84073313  Yes         /lib64/libunistring.so.2
0x00007f1a5fdefb10  0x00007f1a5fdfa7f3  Yes         /lib64/libtasn1.so.6
0x00007f1a5fbbe480  0x00007f1a5fbda90c  Yes         /lib64/libnettle.so.6
0x00007f1a5f98fce0  0x00007f1a5f99d51f  Yes         /lib64/libhogweed.so.4
0x00007f1a5f71da80  0x00007f1a5f76f8c8  Yes         /lib64/libgmp.so.10
0x00007f1a5f50e730  0x00007f1a5f50f7aa  Yes         /usr/lib64/gio/modules/libgiognomeproxy.so
0x00007f1a5d488600  0x00007f1a5d489282  Yes         /usr/lib64/gconv/ISO8859-1.so
0x00007f1a5d262220  0x00007f1a5d26b079  Yes         /lib64/libgeoclue-2.so.0
0x00007f1a5d036160  0x00007f1a5d03c6e1  Yes         /lib64/libnss_files.so.2
0x00007f1a5ce31b30  0x00007f1a5ce32635  Yes         /lib64/libnss_mdns4_minimal.so.2
0x00007f1a5cc2af80  0x00007f1a5cc2e81b  Yes         /lib64/libnss_dns.so.2
0x00007f1a5c8cba60  0x00007f1a5c8e5b85  Yes         /lib64/libnm-gtk.so.0
0x00007f1a5c6b7bd0  0x00007f1a5c6ba942  Yes         /lib64/libnm-glib-vpn.so.1
0x00007f1a5c4a26a0  0x00007f1a5c4a2fb0  Yes         /usr/lib64/gtk-3.0/modules/libpk-gtk-module.so
0x00007f1a5c29bec0  0x00007f1a5c29e080  Yes         /usr/lib64/gtk-3.0/modules/libcanberra-gtk-module.so
0x00007f1a4f244b10  0x00007f1a4f244ef9  Yes         /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so
0x00007f1a4f015260  0x00007f1a4f039135  Yes         /lib64/librsvg-2.so.2
(*): Shared library is missing debugging information.
$1 = 0x0
$2 = 0x0
rax            0x7f1a3bcfffe8	139750649364456
rbx            0x5574e386c420	93960521827360
rcx            0x0	0
rdx            0x5574e386c420	93960521827360
rsi            0x7f1ad0ec4260	139753151021664
rdi            0x5574e386c420	93960521827360
rbp            0x5574e3a7fe70	0x5574e3a7fe70
rsp            0x7ffdc71e60f0	0x7ffdc71e60f0
r8             0x5574e44dd780	93960534873984
r9             0xa	10
r10            0x20	32
r11            0x33	51
r12            0x5574e386c420	93960521827360
r13            0x7f1ad21aa280	139753170838144
r14            0x7f1ad1edf5d0	139753167910352
r15            0x5574e3a7fe70	93960524004976
rip            0x7f1ad0ec4325	0x7f1ad0ec4325 <closure_clear_idle(void*)+197>
eflags         0x10206	[ PF IF RF ]
cs             0x33	51
ss             0x2b	43
ds             0x0	0
es             0x0	0
fs             0x0	0
gs             0x0	0
Dump of assembler code for function closure_clear_idle(void*):
   0x00007f1ad0ec4260 <+0>:	push   %rbp
   0x00007f1ad0ec4261 <+1>:	push   %rbx
   0x00007f1ad0ec4262 <+2>:	mov    %rdi,%rbx
   0x00007f1ad0ec4265 <+5>:	sub    $0x8,%rsp
   0x00007f1ad0ec4269 <+9>:	cmpb   $0x0,0x30(%rdi)
   0x00007f1ad0ec426d <+13>:	je     0x7f1ad0ec4310 <closure_clear_idle(void*)+176>
   0x00007f1ad0ec4273 <+19>:	mov    0x48(%rdi),%rbp
   0x00007f1ad0ec4277 <+23>:	test   %rbp,%rbp
   0x00007f1ad0ec427a <+26>:	je     0x7f1ad0ec4291 <closure_clear_idle(void*)+49>
   0x00007f1ad0ec427c <+28>:	mov    %rbp,%rdi
   0x00007f1ad0ec427f <+31>:	callq  0x7f1ad0eb7490
   0x00007f1ad0ec4284 <+36>:	mov    $0x20,%esi
   0x00007f1ad0ec4289 <+41>:	mov    %rbp,%rdi
   0x00007f1ad0ec428c <+44>:	callq  0x7f1ad0eb7ab0
   0x00007f1ad0ec4291 <+49>:	cmpb   $0x0,0x31(%rbx)
   0x00007f1ad0ec4295 <+53>:	movq   $0x0,0x48(%rbx)
   0x00007f1ad0ec429d <+61>:	movb   $0x0,0x30(%rbx)
   0x00007f1ad0ec42a1 <+65>:	je     0x7f1ad0ec42d0 <closure_clear_idle(void*)+112>
   0x00007f1ad0ec42a3 <+67>:	mov    0x38(%rbx),%rdi
   0x00007f1ad0ec42a7 <+71>:	callq  0x7f1ad0eb6c90
   0x00007f1ad0ec42ac <+76>:	mov    $0x50,%esi
   0x00007f1ad0ec42b1 <+81>:	mov    %rax,%rdi
   0x00007f1ad0ec42b4 <+84>:	callq  0x7f1ad0eb6f48
   0x00007f1ad0ec42b9 <+89>:	mov    0x293998(%rip),%rsi        # 0x7f1ad1157c58
   0x00007f1ad0ec42c0 <+96>:	lea    0x30(%rbx),%rdx
   0x00007f1ad0ec42c4 <+100>:	mov    %rax,%rdi
   0x00007f1ad0ec42c7 <+103>:	callq  0x7f1ad0eb8030
   0x00007f1ad0ec42cc <+108>:	movb   $0x0,0x31(%rbx)
   0x00007f1ad0ec42d0 <+112>:	movq   $0x0,0x38(%rbx)
   0x00007f1ad0ec42d8 <+120>:	movq   $0x0,0x50(%rbx)
   0x00007f1ad0ec42e0 <+128>:	movq   $0x0,0x58(%rbx)
   0x00007f1ad0ec42e8 <+136>:	movq   $0x0,0x28(%rbx)
   0x00007f1ad0ec42f0 <+144>:	movq   $0x0,0x20(%rbx)
   0x00007f1ad0ec42f8 <+152>:	mov    %rbx,%rdi
   0x00007f1ad0ec42fb <+155>:	movl   $0x0,0x60(%rbx)
   0x00007f1ad0ec4302 <+162>:	callq  0x7f1ad0eb8230
   0x00007f1ad0ec4307 <+167>:	add    $0x8,%rsp
   0x00007f1ad0ec430b <+171>:	xor    %eax,%eax
   0x00007f1ad0ec430d <+173>:	pop    %rbx
   0x00007f1ad0ec430e <+174>:	pop    %rbp
   0x00007f1ad0ec430f <+175>:	retq   
   0x00007f1ad0ec4310 <+176>:	mov    0x40(%rdi),%rax
   0x00007f1ad0ec4314 <+180>:	test   %rax,%rax
   0x00007f1ad0ec4317 <+183>:	je     0x7f1ad0ec432a <closure_clear_idle(void*)+202>
   0x00007f1ad0ec4319 <+185>:	and    $0xfffffffffff00000,%rax
   0x00007f1ad0ec431f <+191>:	or     $0xfffe8,%rax
=> 0x00007f1ad0ec4325 <+197>:	testb  $0x1,(%rax)
   0x00007f1ad0ec4328 <+200>:	jne    0x7f1ad0ec4338 <closure_clear_idle(void*)+216>
   0x00007f1ad0ec432a <+202>:	movq   $0x0,0x40(%rbx)
   0x00007f1ad0ec4332 <+210>:	jmp    0x7f1ad0ec42e8 <closure_clear_idle(void*)+136>
   0x00007f1ad0ec4334 <+212>:	nopl   0x0(%rax)
   0x00007f1ad0ec4338 <+216>:	lea    0x40(%rdi),%rdi
   0x00007f1ad0ec433c <+220>:	callq  0x7f1ad0eb73d8
   0x00007f1ad0ec4341 <+225>:	movq   $0x0,0x40(%rbx)
   0x00007f1ad0ec4349 <+233>:	jmp    0x7f1ad0ec42e8 <closure_clear_idle(void*)+136>
End of assembler dump.
== EXPLOITABLE ==
~~~

I just hit this too, without doing anything out of the ordinary. I have a core dump and it matches the one in comment 4.

FWIW, the 'v' in needsPostBarrier points to invalid memory according to gdb.

I'm running gnome-shell from git, mozjs-38.0.0 from jhbuild, and I'm on 0963b42d93d2e3933deb020a8e2ce5295e9a89f3 on gjs.

I'll wait with upgrading for a bit if anyone wants me to run some gdb commands on the dump.

I don't think this is triggered by any specific action. Sometimes I just come to my computer and I am welcomed by login screen, since GS crashed.

Also, what is interesting, I am using two computers, both running quite recent Fedora Rawhide and on one of them GS crashes all the time, while I can't remember it would happen on the other computer.

Created attachment 357403 [details] [review]
closure: Reset object before idle invalidation

This removes the root or the weak pointer on the closure's associated JS
object before scheduling an idle invalidation. This is because the JS
engine may try to relocate the old pointer when resetting, so we need to
do this while the old pointer is still valid.

Please try the above patch. It should apply to either master or gnome-3-24. I'm not sure it will work, but based on the stack trace I think it's a reasonable guess.

I also experienced bug 783935 and having upgraded to gjs 1.48.6 I now intermittently experience a crash of gnome-shell. For me the stacktrace is slightly different to the one in comment 4:

+ Trace 237799

I will try attachment 357403 [details] [review] and see if I can still reproduce the crash. (I don't know any way of reproducing it other than waiting on average a few days).

For me it happenned while I was using chrome, after a period of about 5 minutes during which I experienced occasional momentary freezes where the cursor stopped moving.

This is Fedora package with (hopefully) applied the patch from comment #7. Going to give it try ...

And here is the link :)

https://koji.fedoraproject.org/koji/taskinfo?taskID=21246956

I've been using the latest Fedora 26 libgjs patched with attachment 357403 [details] [review] and it seems that the crashes are gone for me now. Hurray!

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

Unfortunately I realized that the patch breaks an invariant required by the garbage collector: you can't stop tracing an object in the middle of garbage collection. So, with the patch the GJS test suite will assert if run in GC barrier verification mode.

Try the following patch instead.

(By the way, who set this as a blocker for 3.26? Since it is intermittent and only affects a small number of people, I don't agree it's a blocker.)

Created attachment 357764 [details] [review]
util-root: Skip barrier in reset() on unrooted wrapper

Since we are throwing away whatever the JS::Heap held before, we can skip
the post barrier and just set it directly to its initial value. This
makes it not crash if the GC thing previously held had already been
freed.

The patch in Comment 15 caused more crashes - even if I'm doing nothing.
I don't have debugging symbols for mozjs so I can't help further. :-(


Reading symbols from /usr/bin/gnome-shell...done.
[New LWP 1369]
[New LWP 1413]
[New LWP 1370]
[New LWP 1403]
[New LWP 1371]
[New LWP 1557]
[New LWP 1373]
[New LWP 1408]
[New LWP 1407]
[New LWP 1409]
[New LWP 1414]
[New LWP 1410]
[New LWP 1411]
[New LWP 1412]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/usr/bin/gnome-shell'.
Program terminated with signal SIGSEGV, Segmentation fault.

+ Trace 237806

Created attachment 357766 [details]
Full stacktrace

Managed to obtain a full stack trace. The crash is due to the patch in comment 15.

(In reply to Philip Chimento from comment #14)
> (By the way, who set this as a blocker for 3.26? Since it is intermittent
> and only affects a small number of people, I don't agree it's a blocker.)

Erm, this is happening with 3.24 too and it makes gnome3 almost unusable since a crashing shell means you loose everything with the new wayland default (I've switched back to GNOME on Xorg to mitigate the pain somewhat, still this is very annoying).

But you're right this should not have been made a blocker for 3.26, this (well all the different gnome-shell crashes in 3.24 of which this is only 1) should have been a blocker for 3.24. Shipping a new release with know crashing bugs confirmed by multiple people is really a good way to drive people away from using GNOME.

So IMHO the blocker status here is very valid.

I am using the patch from comment #7 for almost two days now and so far no crash. Have not tried the comment #15 patch yet. Not sure if I should given the recent comments ...

(In reply to Hans de Goede from comment #18)
> (In reply to Philip Chimento from comment #14)
> > (By the way, who set this as a blocker for 3.26? Since it is intermittent
> > and only affects a small number of people, I don't agree it's a blocker.)
> 
> Erm, this is happening with 3.24 too and it makes gnome3 almost unusable
> since a crashing shell means you loose everything with the new wayland
> default (I've switched back to GNOME on Xorg to mitigate the pain somewhat,
> still this is very annoying).
> 
> But you're right this should not have been made a blocker for 3.26, this
> (well all the different gnome-shell crashes in 3.24 of which this is only 1)
> should have been a blocker for 3.24. Shipping a new release with know
> crashing bugs confirmed by multiple people is really a good way to drive
> people away from using GNOME.
> 
> So IMHO the blocker status here is very valid.

I understand this is very frustrating for you but from asking around on IRC around the time of the 3.24 release, my understanding is that only a small fraction of users are affected by these crashes.

What's more, setting blocker status is not going to get the crash fixed any faster. It's only me working on it, throwing patches into the void to see if they stick, and I don't have any control over whether that happens by 3.26. I myself cannot reproduce any of the 3.24 crashes (except one with great difficulty that is now fixed.) I didn't even get any reports of the 3.24 crashes until after 3.24 was released, so it's impossible for them to have been blockers for 3.24!

If this is crashing your system often and you consider it a blocker, then I invite you to fire up your text editor and help me out, since you can much more easily check if something works!

Created attachment 357835 [details] [review]
util-root: Skip barrier in reset() on unrooted wrapper

Since we are throwing away whatever the JS::Heap held before, we can skip
the post barrier and just set it directly to its initial value. This
makes it not crash if the GC thing previously held had already been
freed.

Try this patch? It's a slightly different way of doing the same thing that I hope will avoid the new crashes.

Otherwise we will have to consider a different approach, I think.

Unfortunately, the new patch still causes more crashes. The stack strace is almost identical to the old one.

(In reply to Philip Chimento from comment #20)
> I myself cannot reproduce any of the 3.24 crashes
I'm on 3.24. Maybe you can check bug #785856. Many users of Netease Cloud Music are reporting the same issue - their gnome-shell crashes all the time. Other than this, gnome-shell is fairly stable. I guess its misuse of something pushed GJS to its limit...

Created attachment 357848 [details]
stacktrace (#7)

Out of curiosity I tried the patch in comment 7, but no luck. Not sure if this stacktrace is useful.

Hi,

I'm not sure this will be helpful or not, but, are there any common extensions being used by folks affected by this?

The reason I'm asking, is I'm a contributor on cinnamon (yes I know, sorry) - we had some issues quite a while back (years) where we were getting crashes with StLabel instances.  The internal ClutterText child gets destroyed during st_label_dispose().

There were occasions where we were getting crashes due to attempting to set the text on a label where the label had begun but not completed full GC.  This was usually based off some Mainloop timer where we had an anonymous callback referencing the label.

The only reason I ask about extensions is that I had added a warning for when this occurred in st_label_set_text() to help future prevention, and a few of our users that are experiencing this current issue seem to be running one extension in common - which, it turns out, is triggering these warnings occasionally.)

I'm not sure if this is a cause or an effect or if it relates at all to this issue.  I'm attempting to construct a script that will reproduce our old issue, and see if the trace is similar.  But it may be a question to ask the reporters here, regarding enabled extensions.

Actually... just browsing thru some code, I wonder if there's an error here:

https://git.gnome.org/browse/gnome-shell/tree/src/st/st-label.c#n356

g_return_val_if_fail (ST_LABEL (label), NULL);

should be

g_return_val_if_fail (ST_IS_LABEL (label), NULL);

Anyhow, maybe this is helpful.

I'm using the: "Teatime" and "Topicons plus" extensions.

Now that you mention it this does seem to be happening more often (maybe even only?) when the Teatime extension is in use. I have it set to 45 minutes to help remind me to take brakes in a non in your face manner.

I am using "Topicons plus" as well, but I have issues only on one of two my computers ...

The computer on which I'm seeing this has 2 monitors and I think the crash may be related to the mouse cursor having recently crossed the edge between the 2 monitors, but that is a lot of feeling and not a whole lot of fact, which is why I've not mentioned this before. Anyways it would be good to know if other people who are seeing crashes also have more then 1 monitor.

Haha, I guess for the moment the teatime is a bit more in your face than intended.

Extensions I use:
 - taskbar (I'm not sure that gnome-shell has ever crashed for me with this one disabled)
 - frippery move clock
 - alternate tab

I do usually use multiple screens when the crashes happen, but then I also do a very particular set of other things at the same time. When I'm using two screens, the cursor is going in between the screens all the time but the crashes only happen every few days.

I've been running with the patch in attachment 357403 [details] [review] for almost a week and have had no crashes at all in that time, which is otherwise unusual.

It's clear that the crash is a race condition when garbage collecting disconnected signal handlers.

I am not sure, but I think, that some extensions might connect or disconnect signal handlers in some way that plain gnome-shell doesn't do (much), and that is what causes the crash. If anyone can probe their favourite problematic extension and see if there is a way to create a minimal script that can be run with gjs-console under valgrind, then that would be perfect. (As a starting point you could use something like this test [1] that I wrote for bug 783935.)

In the meantime I will try to remove the problematic code that defers garbage collection of signal handlers altogether, and try a different approach.

(I have no doubt that attachment 357403 [details] [review] fixes this bug, but since I found out it is a misuse of the JS garbage collector, I'm sure it would cause other crashes for other people down the line.)

[1] https://bugzilla.gnome.org/attachment.cgi?id=356448&action=diff#a/installed-tests/js/testEverythingEncapsulated.js_sec2

Just FTR, it might be of your interest to observe the original ABRT report in RH Bugzilla:

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

There are already 91 people subscribed, some claiming that the patch from comment #7, which is now applied in F26 does not work for them:

https://bugzilla.redhat.com/show_bug.cgi?id=1444365#c111

Created attachment 358060 [details]
Stacktrace of gnome-shell crash when playing video in vlc

I can trigger this fairly reliably as follows:

 - Compile vlc using this patched PKGBUILD: https://github.com/hedgepigdaniel/pkgbuild-vlc (The reason for the patch is to avoid this bug: https://trac.videolan.org/vlc/ticket/17829, https://bugzilla.gnome.org/show_bug.cgi?id=777428, which happens when the cursor is moved over the seek bar while a video is playing in full screen. This usually causes the shell to hang before this crash happens)
 - Play a video in full screen.
 - Right click repeatedly on the video
 - repeatedly roll the mouse over the seek bar (notice a momentary freeze)
 - repeatedly double click on the video to change between full screen and windowed mode

I should add that the above is with the patch from comment 7 and attachment 357403 [details] [review]

OK, with the additional information that attachment 357403 [details] [review] doesn't even fix the bug, we should leave it entirely out of consideration from now on.

I tried an alternative approach altogether on bug 786668. This is a pretty invasive refactor so if it's possible to make a simpler band-aid fix for GNOME 3.24, I'd prefer to do that. For that I need a valgrind log of the crash to see where the closure is being freed. If you can provide this, please help. See bug 783935 for instructions.

If not, then I will try to backport the alternative approach in the least invasive way possible. That is not without risk, since who knows whether it might actually make things worse; all the crashes we've had due to this part of the code have had in common that they affect only a relatively small number of people and are intermittent, so that could just as well happen with the new fix.

PS. I also learned that only the GNOME release team can set blocker status. I still don't agree with it, since the blocker status is meaningless if no-one else but me is working on patches, and I can't reproduce the bug in the first place! But I apologize for assuming it was a commenter, I probably came across as a bit annoyed.

Created attachment 358257 [details] [review]
closure: Remove pointer to runtime

This isn't used at all. Backported from master in order to apply fixes
for closure invalidation.

https://bugzilla.gnome.org/show_bug.cgi?id=786668

Created attachment 358258 [details] [review]
Revert freeing closures in idle handler

This turned out to cause a lot of problems; it has been responsible for
almost all of the crashes in gnome-shell since 1.48. We revert back to
the original code modulo a few improvements that have been made along the
way.

This state at least does not crash in the test suite, although it is
definitely not correct since it breaks SpiderMonkey's garbage collector
pre barrier verification mode (the reason the change was made in the
first place.) That still must be fixed using a different approach.

This partially reverts commits [41b78ae], [db3e387], [bace908],
[9eb4a2b], [2593d3d], and [334ba96].

https://bugzilla.gnome.org/show_bug.cgi?id=786668

Created attachment 358259 [details] [review]
closure: Prevent collection of invalidated closure

It's not possible to stop tracing an object in the middle of GC. However,
by using JS::ExposeObjectToActiveJS(), it is possible to mark an object
as reachable for the duration of one GC. This is exactly what we need for
closures, to keep the closure's callable object from disappearing while
GC is going on.

https://bugzilla.gnome.org/show_bug.cgi?id=786668

OK, these patches are versions of the ones from bug 786668 that apply cleanly to 1.48.6. Please let me know if they solve the problem for you.

Review of attachment 358257 [details] [review]:

OK

Review of attachment 358258 [details] [review]:

Looks good here too.

Review of attachment 358259 [details] [review]:

This looks OK to me, but I'd be happier if people here could test the patchset.
Philip also mentioned to me he's going to check on Mozilla IRC whether we need any additional check for Spidermonkey 38 like we do for later versions.

This should be Fedora scratch build with patches applied:

https://koji.fedoraproject.org/koji/taskinfo?taskID=21426267

Here's a PKGBUILD for Arch with these patches applied and debug symbols enabled: https://github.com/hedgepigdaniel/pkgbuild-gjs/archive/45e78a8b320cb148ccd7b77003acec4b9d419ff2.zip

Thanks Philip! Hopefully this solves the problem.

I don't think this is caused by the patches but there are a few tests that fail during the build for me - cause for concern?:

FAIL: installed-tests/js/testLocale.js 2 JS_SetLocaleCallbacks toLocaleDateString() works
ERROR: installed-tests/js/testLocale.js - exited with status 1
FAIL: installed-tests/js/testCairo.js 22 Cairo context has methods when created from a C function
ERROR: installed-tests/js/testCairo.js - exited with status 1

Created attachment 358291 [details]
Crash

Observations
 - A similar crash still occurs when using vlc and mousing over the seek bar repeatedly and then going between full screen and windowed mode, stacktrace attached
 - Login is a bit faster
 - There is no longer a momentary freeze of the cursor when tooltips appear, both in vlc when mousing over the seek bar in full screen mode, and in chrome when mousing over a tab title

I will try to collect a valgrind log of the crash

Created attachment 358292 [details]
Valgrind log of playing with VLC (No crash, but some invalid memory access)

I had to disable all my shell extensions in order to log in successfully. Not sure if this is why it didn't crash, but there was some invalid memory access when opening vlc.

(In reply to Daniel Playfair Cal from comment #44)
> I don't think this is caused by the patches but there are a few tests that
> fail during the build for me - cause for concern?:

Yes, that's concerning - can you attach the test-suite.log from the build please?

(In reply to Daniel Playfair Cal from comment #46)
> I had to disable all my shell extensions in order to log in successfully.
> Not sure if this is why it didn't crash, but there was some invalid memory
> access when opening vlc.

From the difference between the stack trace and the valgrind invalid reads, I expect that disabling the shell extensions made the difference. The invalid reads we can blame almost for certain on GTK, there's no Javascript in the valgrind log at all. But it also looks like the invalid read is not the reason for the crash.

If you can figure out which extension causes the crash and run the shell with only that extension, maybe you can get a successful valgrind log of the crash happening?

Created attachment 358294 [details]
test-suite.log

Ok, here's the test log.

One of them looks like somebody got confused and thought the week started on Sunday, when in fact it starts on Monday. "Segunda-feira" is Monday, and "Tersa-feira" is Tuesday.

I've added debug symbols for gtk and cairo, I'll try to work out which extension is the problem. Hopefully its not taskbar, because then I'll run into this: https://bugzilla.gnome.org/show_bug.cgi?id=786186. Potentially I'll have more luck debugging that now that I know that gjs_dumpstack() sometimes doesn't print to the gdb console but does log to stdout.

(In reply to Daniel Playfair Cal from comment #48)
> Created attachment 358294 [details]
> test-suite.log
> 
> Ok, here's the test log.
> 
> One of them looks like somebody got confused and thought the week started on
> Sunday, when in fact it starts on Monday. "Segunda-feira" is Monday, and
> "Tersa-feira" is Tuesday.

Well, 12/15/1981 was in fact a Tuesday, so there's something going wrong in the date library there, and I don't understand why this wouldn't have failed before on your machine...

> I've added debug symbols for gtk and cairo, I'll try to work out which
> extension is the problem. Hopefully its not taskbar, because then I'll run
> into this: https://bugzilla.gnome.org/show_bug.cgi?id=786186. Potentially
> I'll have more luck debugging that now that I know that gjs_dumpstack()
> sometimes doesn't print to the gdb console but does log to stdout.

It should always be printing to stderr (via g_printerr()), maybe GDB is not always redirecting the stderr output correctly?

Thanks for your help.

Created attachment 358380 [details] [review]
object: Only invalidate signals in finalizer

The signal closures will get invalidated anyway in the finalizer, so no
need to do it in the weak pointer callback, which seems to cause
problems.

This may cause references to signal handlers to live a bit longer than
they previously would, but in any case the reference will be dropped when
the owning object is finalized.

Try this patch in addition to the other ones? I'm not sure it will do anything but it might...

I am running the build from comment 43 for 1.5 days and so far so good. The only downside is that now G-S crashes due to bug 780861 :/

I didn't know about bug 780861, that looks like a solution for a different bug report that I got. Thanks for pointing it out.

I'm hesitant to commit these patches, it apparently solves your problem but not Daniel's. I have an intuition that these patches will make things better generally since there is less asynchronous stuff going on and therefore less chance of a race condition, but I'd like to have more than two data points before making a decision...

Created attachment 358459 [details]
crash stacktrace

With all the patches applied and all extensions disabled, I am still affected by this. I don't know how to use Valgrind, sorry...

Created attachment 358461 [details]
Slightly different stacktrace

Here's a stacktrace of the crash that occurred for me in the same circumstances (mousing over vlc seek bar)

I have applied patch 358830 aswell, here is my current PKGBUILD: https://github.com/hedgepigdaniel/pkgbuild-gjs/tree/604daffaed58c8a41a9fc9f2dfc6699806b59d99

I also added a global.log() statement at the beginning and end of most functions in the taskbar extension. This causes a freeze of a few seconds whenever mouseover windows appear or dissappear, which persists even after disabling taskbar (taskbar seems to run quite alot of code when windows are added and removed). The global.log statements also make this crash occur very quickly. Before the latest patch I still had the crash in insideNursery with the global.log statements.

Immediately before the crash there were huge quantities of the following 3 lines repeadted in the log for gnome-shell:

clutter_layout_manager_get_child_meta: assertion 'CLUTTER_IS_LAYOUT_MANAGER (manager)' failed
g_object_set: assertion 'G_IS_OBJECT (object)' failed
g_object_set: assertion 'G_IS_OBJECT (object)' failed

At other times there is exactly one occurence of the above three lines after the following function starts running: https://github.com/zpydr/gnome-shell-extension-taskbar/blob/429a196b9f58818bf000cd3ac497f2a71f706ab1/extension.js#L2503

In between them, a few occurences of

org.gnome.Shell.desktop[1110]: Window manager warning: Invalid WM_TRANSIENT_FOR window 0x2c00007 specified for 0x2c0001f (vlc).

Segmentation faults ocurring sporadically on Arch Linux in gnome-session 3.24.1-1, gjs 1.48.6-1.

I get the following stack trace:

Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/usr/bin/gnome-shell'.
Program terminated with signal SIGSEGV, Segmentation fault.

+ Trace 237875

Additional info:

I am not sure how to reproduce it. I think it happens mostly when using Eclipse
Eclipse Java EE IDE for Web Developers
Version: Neon.3 Release (4.6.3)
Build id: 20170314-1500

I also have guake 0.8.10-1 active.

v_bachvarov: Is this with GJS 1.48.6 built with the patches attached to this bug report?

Mike: what distro are you on? Fedora has gnome-valgrind-session which lets you log into an entire gnome-shell session which is then run under valgrind.

Daniel: I've got VLC and the Task Bar extension by zpydr installed and was trying some more to make the crash happen as you described it, but no luck. From all the descriptions, yours seems the easiest way to get it to happen reliably. Can you give me any more info? How long do you have to mouse over VLC's seek bar and how many times do you have to switch between fullscreen and windowed?

Ah cool. I found that patching the taskbar code by adding a global.log statement at the beginning of each function made it much likely to crash. After doing the mousing over there seem to be lots of things that can trigger a crash besides switching between full screen and windowed - sometimes it doesn't seem to happen in response to any particular action.

I generally open vlc in full screen mode and move the mouse repeatedly vertically over the seek bar (do it slowly and you can see a tooltip popping up showing the timecode). Sometimes there is a UI bug where the seek bar goes grey and the tooltip doesn't open on rollover, this can be avoided by clicking on it once to seek. As the tooltip closes there is a momentary freeze where the cursor stops moving (with enough print statements it becomes multiple seconds). Sometimes if I leave the video playing and do other stuff for a while and come back to it it crashes almost immediately, other times it takes 5-10 minutes, and sometimes a long time and I reboot before trying again.

After the latest patch the majority of the patches are still the insideNursery type, the one in attachment 358461 [details] only happened once.

This kind of thing: https://github.com/zpydr/gnome-shell-extension-taskbar/compare/master...hedgepigdaniel:insideNursery?expand=1

Philip Chimento: I did not patch anything manually. I'll apply the patches and retest.
Just a little help pls: The patches are the 4 attachments by you that have a "Diff" link, right?
I want to make sure I am testing the right code.

Actually, try just the first three to begin with; the ones marked "accepted-commit-now".

Philip Chimento: Nevermind, I have just realized that the call stack is identical to the one reported by RedHat / Vít Ondruch with comment 4. So this is a duplicate.

OK, thanks. If you still get a chance to see if the patches fix the problem for you, I'd really appreciate it.

Also using topIcions: topIcons@adel.gadllah@gmail.com'

Without any patches applied, got this stack trace which seems to go down to js38

+ Trace 237907

Just had the crash despite patches applied (from Daniel's PKGBUILD https://bugzilla.gnome.org/show_bug.cgi?id=785657#c44)

+ Trace 237908

Another one (happened fast)

+ Trace 237909

I am beginning to suspect the media integration in the top bar (thumbnail and music controls); i'm using Spotify, and i have been pausing playback for the last hours and i didn't get the crash anymore. Anyone else noticing an increase of crashes when using a music player that does desktop integration ?

(In reply to Florent Thiéry from comment #67)
> I am beginning to suspect the media integration in the top bar (thumbnail
> and music controls); i'm using Spotify, and i have been pausing playback for
> the last hours and i didn't get the crash anymore. Anyone else noticing an
> increase of crashes when using a music player that does desktop integration ?

I can confirm this, but I'm not sure if I'm having exactly the same issue as yours.

I'm getting crashes when using Netease Cloud Music, the current version of which has a broken MPRIS implementation -- its "xesam:artist" is a string, not a list of strings.

Every second an update is requested by gnome-shell (not sure it's gnome-shell or the music player), which will result in an error like this:
        JS ERROR: Exception in callback for signal: changed: TypeError: this._player.trackArtists.join is not a function
        MediaMessage<._update@resource:///org/gnome/shell/ui/mpris.js:92:23
        wrapper@resource:///org/gnome/gjs/modules/lang.js:178:22
        _emit@resource:///org/gnome/gjs/modules/signals.js:126:27
        MprisPlayer<._updateState@resource:///org/gnome/shell/ui/mpris.js:214:9
        wrapper@resource:///org/gnome/gjs/modules/lang.js:178:22

Now, gnome-shell becomes more crash-prone... Just now I was testing again, and caught two more crashes. Other than this music player with broken MPRIS implementation, other music players work well, and gnome-shell is fairly stable.


(In reply to Philip Chimento from comment #57)
> Mike: what distro are you on? Fedora has gnome-valgrind-session which lets
> you log into an entire gnome-shell session which is then run under valgrind.

Arch Linux. It seems there's no such thing here...

Philip Chimento: I tried to test the patches, but they did not fit the source I had 1.48.6. Unfortunately I do not have the time to go into the implementation and integrate them backwards.
I tried installing the latest version but I had to compile dependencies (mozdev-52) and it's not feasible at the moment.

If you could give me a snippet to apply the patches easily to 1.48.6, I would gladly test it.

I used this commands but the code does not fit:

% patch -p1 < ../../patches/closure-Remove-pointer-to-runtime.patch
patching file gi/closure.cpp
patch unexpectedly ends in middle of line

update: I was able to patch by getting the raw unified diff. However, the patched files were syntactically incorrect and had compiler errors. The patches are not compatible with the older version of the source 1.48.6.

Mike: For Arch there is https://github.com/hedgepigdaniel/gnome-shell-valgrind thanks to Daniel. Also, is there any way to install Netease in Fedora? The site only has downloads for Deepin and Ubuntu.

Bachvarov: As far as I know these patches are correct for 1.48.6, since I created them by applying the patches from bug 786668 to 1.48.6 and fixing them up. "Patch unexpectedly ends in middle of line" might indicate that your download was interrupted, maybe?

(In reply to Philip Chimento from comment #71)
> Also, is there any way to install Netease in Fedora? The site only has
> downloads for Deepin and Ubuntu.

I searched but found no package for latest version.  Existing ones are badly outdated.  There are tarballs from Deepin:
http://cdimage.deepin.com/applications/netease-cloud-music/

Configuration (https://www.deepin.org/cooperative/netease-cloud-music/)

    sudo chown root:root usr/lib/netease-cloud-music/chrome-sandbox
    sudo chmod 4755 usr/lib/netease-cloud-music/chrome-sandbox

Run `usr/lib/netease-cloud-music/netease-cloud-music`. The user interface is in pure Chinese.
(Some translations which might be helpful: http://i.imgur.com/IAeKuJO.png)

Tried the Valgrind session just now.  Unfortunately, everything was so slow, that I couldn't even see the desktop after waiting for more than 30 minutes.  So I can't help here. :-(

Mike: The slowness is normal, since Valgrind is tracking every read/write and memory allocation. Maybe you could leave it on overnight? I only ask because I'm quite desperate for a valgrind log of the new crash after the patches are applied.

I'm not sure why but the patch (based on daniel's PKGBUILD at https://bugzilla.gnome.org/show_bug.cgi?id=785657#c44)  seems to improve the situation a lot already, didn't crash at all today. Maybe a reboot was required (not just Alt+F2 + r) ?

Just had to write it...

Program terminated with signal SIGSEGV, Segmentation fault.

+ Trace 237917

Philip Chimento: Can you please provide the commit id, I need to checkout and apply the patches to?

I'll try:
git clone ...
git checkout <commit id>
patch ...
patch ...
patch ...

gnome-3-24 is the branch name.

Philip Chimento: Alright! I was able to apply the patches. You were right, the patch files were corrupted.

I installed the patched gjs and I'll let you know in a couple of days if everything is alright. Thanks for the support!

I'm giving up... 

Valgrind session crashed and dumped 1.2 GiB core (SEGV). :-( One more crash 5 minutes ago.

I have no idea what I've been doing wrong. Hopefully I did do something wrong and the bug is fixed considering the positive results from others...

Some recent crashes recorded by coredumpctl:
Sat 2017-09-02 10:49:42 CST     940  1000  1000  11 none      /usr/lib/valgrind/memcheck-amd64-linux
Sat 2017-09-02 15:45:11 CST    2182  1000  1000  11 missing   /usr/bin/gnome-shell
Sat 2017-09-02 15:45:13 CST    2995  1000  1000  11 missing   /usr/lib/netease-cloud-music/netease-cloud-music
Sat 2017-09-02 19:14:29 CST     930  1000  1000  11 present   /usr/bin/gnome-shell
Sat 2017-09-02 19:14:32 CST    1787  1000  1000  11 present   /usr/lib/netease-cloud-music/netease-cloud-music

@Mike whats the stacktrace from the coredump? (`coredump --reverse gdb`)

Maybe you just created a valgrind log of the crash? Is there a log named <date>.valgrind in ~/.valgrind-session ?

I'll try to make a valgrind session with taskbar enabled work by leaving it on overnight.Hopefully after enabling and disabling taskbar hundreds of times due to bug 786186 it does eventually reach some kind of equilibrium and starts the session.

Philip Chimento: I have not had the crash for a couple of days now. Good job, thank you!
To summarize: Arch Linux, gtk3 3.22.19-2, gjs 1.48.6-1, patched with the first 3 attachments. The crash seems solved.

Philip Chimento: (:  Right after reporting the patched crashed again (this time I believe with another stack trace). It looks like another bug (probably an invalid pointer was passed to release_native_object()).

I hope this helps:

(gdb) bt

+ Trace 237924

We posted at the same time and I was going to say thanks, but other people still get a crash, so it's not solved yet :-) And now indeed it's still crashing for you.

However, it is a point in favour of committing these patches and releasing 1.48.7, as it seems that at least the crashes are not _more_ frequent, and seem to be actually _less_ frequent... is that the case for everyone?

I have the feeling it get's triggered by a certain chain of events but can't tell for sure. It happens to me mostly (if not always) when working in JDT Eclipse Neon.
Let me know if I can trace that back to the GUI level.
Can I find out somehow which .js file caused that and what was the Javascript stack trace?

Created attachment 359101 [details]
System log around the segmentation fault time (see Comment 83)

Relates to comment 83.
Unfortunately there is no other logged activity immediately before the segfault.
The js files might help in understanding the bug.

I believe the problem is still in gjs/closure.cpp but if you can track down in which JS file it happens, that may help me to debug and/or add a minimal test case for the crash.

If you run gnome-shell under GDB, you can use the command "call gjs_dumpstack()" to get a stack trace. (Unfortunately this doesn't work in coredumpctl because it requires executing code, and with coredumpctl the process is already dead.)

To do that, log out, pick a "GNOME on Xorg" session at the login screen, switch to a virtual terminal with (e.g.) Ctrl+Alt+F2, log in there, and enter "gdb --args gnome-shell --replace", then "run". Switch back to graphical mode with Ctrl+Alt+F1 or F7 depending on your distro. Things will run slower, and when the crash happens the screen will freeze. Switch back to the virtual terminal with Ctrl+Alt+F2 and you should be dropped into a gdb prompt, where you can do "call gjs_dumpstack()". Also a "thread apply all bt full" would be helpful.

I'm too still seeing crashes sometines, but indeed way less frequent. It went from "man this is annoying" to "hey it crashed, that has not happened in a while". This is with gnome3 on xorg with topicons and a media player using mpris. Anyways big +1 from me for doing a 1.48.7 .

(In reply to Philip Chimento from comment #84)
> However, it is a point in favour of committing these patches and releasing
> 1.48.7, as it seems that at least the crashes are not _more_ frequent, and
> seem to be actually _less_ frequent... is that the case for everyone?

Yes, crashes are much less frequent for me.

I haven't noticed any difference after applying the patches. It's possible it has become less frequent but I'm not sure.

Created attachment 359184 [details]
GDB log trying to get a JS stacktrace

I tried to do call gjs_dumpstack() in gdb when the crash happens but it hangs :(

I printed a stacktrace of where it hangs though.

Philip Chimento: Very helpful instructions, I will try it out when I have time.
The crash happens with me much less frequently though. So the patches definitely helped a lot.

1.48.7 was just released with these patches.

Daniel, from your stack trace it looks like this is happening during garbage collection, so I guess gjs_dumpstack() will not work.

A valgrind trace would still be useful because it will say where the memory involved in the invalid read was freed.

Fedora update: https://bodhi.fedoraproject.org/updates/gjs-1.48.7-1.fc26

I had this issue on Fedora 26 and the update in bodhi fixed it for me. I'm happy I can go make a coffee and come back to everything how it was (instead of gjs crashing gnome-shell killing wayland and then all my apps). Many thanks! 


However, on my personal laptop I upgraded to Fedora 27-pre-beta... and I'm experiencing the same crash (or very similar gjs one if not the same) even though it's version gjs-1.49.3-3.fc27. 

I guess the fix hasn't been included in 1.49 included in F27 (yet)? Or has it and is this a regression or some different/related issue?

F27 should update to 1.49.92 or later to fix this.

Setting NEEDINFO for the time being, looking for:
- reliable way to force a crash
- valgrind trace
- gjs_dumpstack() (which should now work thanks to bug 786186)

The gjs + gnome-shell crash happens for me usually when the screen blanks and I come back to enter my password. 

Between leaving the computer and coming back to wake it up, the crash happens. When I sign back in, it's the sign-in screen instead of the unlock screen and I get a new desktop.


I think it has to do with monitor detection, as I have the internal screen on my laptop off (sometimes with the lid closed) and two external displays (of different types, and one is slower to resume than the other). In my setup, that means there is a good bit of monitor detection going on when the screens blank to power saving mode and then wake back up.

That said, my personal laptop (on F27) is _also_ having issues without an external display. It's during suspend/resume in that case. However, I am guessing the software stack is going through the same motions to find all displays and wake up the internal one.


So, I suggest having an external monitor or two (if possible — even an HDMI capable TV should work) and setting the "blank screen" time in the "power" section of GNOME Settings to 1 minute. And/or plugging and unplugging the external display a bunch of times. 

I am testing with Fedora 27 and btrfs for /home. 
I program in C, or C++, but not familiar with JS api's.

Taskbar is not source code adaptive to the environment (eg, btrfs, ext4, xfs) but only encounters configuration problems when the ~ is under btrfs.

If I migrate ~ from a btrfs system to xfs or ext4, Taskbar configuration works just fine.

From my observation(s), it looks to me that the compiled schema is being mis-interpreted if it is resident on a btrfs file system.  That results in 
the user file (~/.config/dconf/user being corrupted.

I can not configure TB with Wayland but with a few killall -u of the logon with gnome-xorg, I can accomplish a setup, thereafter tb works mostly/always  with the ~ under btrfs

Leslie: That seems unrelated to this problem.

I think I'm hitting this issue on Arch (I see libgjs in stack path).

I'm on gnome-shell 3.26.1. I wasn't able to log into my normal account, I see the desktop briefly, and then crashes back to GDM login screen. I was able to login as root, and then login afterwards as my non-root account which is weird (so not a leftover config issue). 

Environment:
gnome-shell 3.26.1-1
nvidia 387.12-1
linux 4.13.4-1
xorg-server 1.19.4-1



           PID: 6766 (gnome-shell)
           UID: 16430 (pedrum)
           GID: 16430 (pedrum)
        Signal: 5 (TRAP)
     Timestamp: Tue 2017-10-10 14:25:36 PDT (5min ago)
  Command Line: /usr/bin/gnome-shell
    Executable: /usr/bin/gnome-shell
 Control Group: /user.slice/user-16430.slice/session-c4.scope
          Unit: session-c4.scope
         Slice: user-16430.slice
       Session: c4
     Owner UID: 16430 (pedrum)
       Boot ID: 1be78a41cec94c979d59d6b193ee8267
    Machine ID: 50e5b46cf62f492db6108dee9145c6c7
      Hostname: myworkstation.mydomain.com
       Storage: /var/lib/systemd/coredump/core.gnome-shell.16430.1be78a41cec94c979d59d6b193ee8267.6766.1507670736000000.lz4
       Message: Process 6766 (gnome-shell) of user 16430 dumped core.
                
                Stack trace of thread 6766:
                #0  0x00007f9cb29ffcd2 n/a (libglib-2.0.so.0)
                #1  0x00007f9cb29ffecd g_log_default_handler (libglib-2.0.so.0)
                #2  0x000055ac3874d1b8 n/a (gnome-shell)
                #3  0x00007f9cb2a004ef g_logv (libglib-2.0.so.0)
                #4  0x00007f9cb2a00680 g_log (libglib-2.0.so.0)
                #5  0x00007f9cb166bbb8 n/a (libmutter-clutter-1.so)
                #6  0x00007f9cb0a227e4 n/a (libst-1.0.so)
                #7  0x00007f9cb0a08f31 n/a (libst-1.0.so)
                #8  0x00007f9cb165800d n/a (libmutter-clutter-1.so)
                #9  0x00007f9cb165c399 n/a (libmutter-clutter-1.so)
                #10 0x00007f9cb165cfad clutter_actor_allocate (libmutter-clutter-1.so)
                #11 0x00007f9cb165d687 clutter_actor_allocate_preferred_size (libmutter-clutter-1.so)
                #12 0x00007f9cad3711c8 ffi_call_unix64 (libffi.so.6)
                #13 0x00007f9cad370c2a ffi_call (libffi.so.6)
                #14 0x00007f9cb198bcbb n/a (libgjs.so.0)
                #15 0x00007f9cb198d617 n/a (libgjs.so.0)
                #16 0x00007f9cab03c64d n/a (libmozjs-52.so.0)
                #17 0x00007f9cab03c779 n/a (libmozjs-52.so.0)
                #18 0x00007f9caae2c219 n/a (libmozjs-52.so.0)
                #19 0x00001283b7e863c6 n/a (n/a)
                #20 0x00007f9caad2ad3e n/a (libmozjs-52.so.0)
                #21 0x00007f9cab03c14b n/a (libmozjs-52.so.0)
                #22 0x00007f9cab03c46f n/a (libmozjs-52.so.0)
                #23 0x00007f9cab03c779 n/a (libmozjs-52.so.0)
                #24 0x00007f9caaecfb44 _Z20JS_CallFunctionValueP9JSContextN2JS6HandleIP8JSObjectEENS2_INS1_5ValueEEERKNS1_16HandleValueArrayENS1_13MutableHandleIS6_EE (libmozjs-52.so.0)
                #25 0x00007f9cb19b5bf8 gjs_call_function_value (libgjs.so.0)
                #26 0x00007f9cb1985f89 gjs_closure_invoke (libgjs.so.0)
                #27 0x00007f9cb19a46ff n/a (libgjs.so.0)
                #28 0x00007f9cb2cc56f5 g_closure_invoke (libgobject-2.0.so.0)
                #29 0x00007f9cb2cd90b0 n/a (libgobject-2.0.so.0)
                #30 0x00007f9cb2cdd696 g_signal_emit_valist (libgobject-2.0.so.0)
                #31 0x00007f9cb2cde920 g_signal_emit (libgobject-2.0.so.0)
                #32 0x00007f9cb32bf801 n/a (libgnome-shell.so)
                #33 0x00007f9cb165cf6e clutter_actor_allocate (libmutter-clutter-1.so)
                #34 0x00007f9cb165d687 clutter_actor_allocate_preferred_size (libmutter-clutter-1.so)
                #35 0x00007f9cb167c88b n/a (libmutter-clutter-1.so)
                #36 0x00007f9cb164ae39 clutter_actor_set_allocation (libmutter-clutter-1.so)
                #37 0x00007f9cb16a8d2c n/a (libmutter-clutter-1.so)
                #38 0x00007f9cb165cf6e clutter_actor_allocate (libmutter-clutter-1.so)
                #39 0x00007f9cb16a633b n/a (libmutter-clutter-1.so)
                #40 0x00007f9cb164aba6 clutter_actor_get_allocation_box (libmutter-clutter-1.so)
                #41 0x00007f9cb0a014b3 _st_create_shadow_pipeline_from_actor (libst-1.0.so)
                #42 0x00007f9cb0a017ae n/a (libst-1.0.so)
                #43 0x00007f9cb0a0183f n/a (libst-1.0.so)
                #44 0x00007f9cb0a0c298 n/a (libst-1.0.so)
                #45 0x00007f9cb2cddc01 g_signal_emit_valist (libgobject-2.0.so.0)
                #46 0x00007f9cb2cde920 g_signal_emit (libgobject-2.0.so.0)
                #47 0x00007f9cb0a23e8e n/a (libst-1.0.so)
                #48 0x00007f9cb16466dd n/a (libmutter-clutter-1.so)
                #49 0x00007f9cb1649779 n/a (libmutter-clutter-1.so)
                #50 0x00007f9cb16498a1 n/a (libmutter-clutter-1.so)
                #51 0x00007f9cb0a240ad n/a (libst-1.0.so)
                #52 0x00007f9cb16466dd n/a (libmutter-clutter-1.so)
                #53 0x00007f9cb1649779 n/a (libmutter-clutter-1.so)
                #54 0x00007f9cb16498a1 n/a (libmutter-clutter-1.so)
                #55 0x00007f9cb0a240ad n/a (libst-1.0.so)
                #56 0x00007f9cb16466dd n/a (libmutter-clutter-1.so)
                #57 0x00007f9cb1649779 n/a (libmutter-clutter-1.so)
                #58 0x00007f9cb16498a1 n/a (libmutter-clutter-1.so)
                #59 0x00007f9cb0a240ad n/a (libst-1.0.so)
                #60 0x00007f9cb16466dd n/a (libmutter-clutter-1.so)
                #61 0x00007f9cb1649779 n/a (libmutter-clutter-1.so)
                #62 0x00007f9cb16498a1 n/a (libmutter-clutter-1.so)
                #63 0x00007f9cb0a240ad n/a (libst-1.0.so)
                
                Stack trace of thread 6783:
                #0  0x00007f9cb3ab838d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007f9caac24465 n/a (libmozjs-52.so.0)
                #2  0x00007f9caac246b5 n/a (libmozjs-52.so.0)
                #3  0x00007f9cab0222e5 n/a (libmozjs-52.so.0)
                #4  0x00007f9cab042ca2 n/a (libmozjs-52.so.0)
                #5  0x00007f9cb3ab208a start_thread (libpthread.so.0)
                #6  0x00007f9cb37ea1bf __clone (libc.so.6)
                
                Stack trace of thread 6772:
                #0  0x00007f9cb37dfcbb __poll (libc.so.6)
                #1  0x00007f9cb29f6ed3 n/a (libglib-2.0.so.0)
                #2  0x00007f9cb29f6fae g_main_context_iteration (libglib-2.0.so.0)
                #3  0x00007f9cb29f7002 n/a (libglib-2.0.so.0)
                #4  0x00007f9cb29eb1eb n/a (libglib-2.0.so.0)
                #5  0x00007f9cb3ab208a start_thread (libpthread.so.0)
                #6  0x00007f9cb37ea1bf __clone (libc.so.6)
                
                Stack trace of thread 6826:
                #0  0x00007f9cb37e4bb9 syscall (libc.so.6)
                #1  0x00007f9cb2a1e6b1 g_cond_wait (libglib-2.0.so.0)
                #2  0x00007f9caff7c105 n/a (libmutter-cogl-1.so)
                #3  0x00007f9cb29eb1eb n/a (libglib-2.0.so.0)
                #4  0x00007f9cb3ab208a start_thread (libpthread.so.0)
                #5  0x00007f9cb37ea1bf __clone (libc.so.6)
                
                Stack trace of thread 6774:
                #0  0x00007f9cb37dfcbb __poll (libc.so.6)
                #1  0x00007f9cb29f6ed3 n/a (libglib-2.0.so.0)
                #2  0x00007f9cb29f7f42 g_main_loop_run (libglib-2.0.so.0)
                #3  0x00007f9cb2f61e28 n/a (libgio-2.0.so.0)
                #4  0x00007f9cb29eb1eb n/a (libglib-2.0.so.0)
                #5  0x00007f9cb3ab208a start_thread (libpthread.so.0)
                #6  0x00007f9cb37ea1bf __clone (libc.so.6)
                
                Stack trace of thread 6790:
                #0  0x00007f9cb3ab838d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007f9caac24465 n/a (libmozjs-52.so.0)
                #2  0x00007f9caac246b5 n/a (libmozjs-52.so.0)
                #3  0x00007f9cab0222e5 n/a (libmozjs-52.so.0)
                #4  0x00007f9cab042ca2 n/a (libmozjs-52.so.0)
                #5  0x00007f9cb3ab208a start_thread (libpthread.so.0)
                #6  0x00007f9cb37ea1bf __clone (libc.so.6)
                
                Stack trace of thread 6787:
                #0  0x00007f9cb3ab838d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007f9caac24465 n/a (libmozjs-52.so.0)
                #2  0x00007f9caac246b5 n/a (libmozjs-52.so.0)
                #3  0x00007f9cab0222e5 n/a (libmozjs-52.so.0)
                #4  0x00007f9cab042ca2 n/a (libmozjs-52.so.0)
                #5  0x00007f9cb3ab208a start_thread (libpthread.so.0)
                #6  0x00007f9cb37ea1bf __clone (libc.so.6)
                
                Stack trace of thread 6779:
                #0  0x00007f9cb3ab838d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007f9caac24465 n/a (libmozjs-52.so.0)
                #2  0x00007f9caac246b5 n/a (libmozjs-52.so.0)
                #3  0x00007f9cab0222e5 n/a (libmozjs-52.so.0)
                #4  0x00007f9cab042ca2 n/a (libmozjs-52.so.0)
                #5  0x00007f9cb3ab208a start_thread (libpthread.so.0)
                #6  0x00007f9cb37ea1bf __clone (libc.so.6)
                
                Stack trace of thread 6789:
                #0  0x00007f9cb3ab838d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007f9caac24465 n/a (libmozjs-52.so.0)
                #2  0x00007f9caac246b5 n/a (libmozjs-52.so.0)
                #3  0x00007f9cab0222e5 n/a (libmozjs-52.so.0)
                #4  0x00007f9cab042ca2 n/a (libmozjs-52.so.0)
                #5  0x00007f9cb3ab208a start_thread (libpthread.so.0)
                #6  0x00007f9cb37ea1bf __clone (libc.so.6)
                
                Stack trace of thread 6785:
                #0  0x00007f9cb3ab838d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007f9caac24465 n/a (libmozjs-52.so.0)
                #2  0x00007f9caac246b5 n/a (libmozjs-52.so.0)
                #3  0x00007f9cab0222e5 n/a (libmozjs-52.so.0)
                #4  0x00007f9cab042ca2 n/a (libmozjs-52.so.0)
                #5  0x00007f9cb3ab208a start_thread (libpthread.so.0)
                #6  0x00007f9cb37ea1bf __clone (libc.so.6)
                
                Stack trace of thread 6778:
                #0  0x00007f9cb37dfcbb __poll (libc.so.6)
                #1  0x00007f9c9430a773 n/a (libpulse.so.0)
                #2  0x00007f9c942fbbd0 pa_mainloop_poll (libpulse.so.0)
                #3  0x00007f9c942fc271 pa_mainloop_iterate (libpulse.so.0)
                #4  0x00007f9c942fc301 pa_mainloop_run (libpulse.so.0)
                #5  0x00007f9c9430a6ae n/a (libpulse.so.0)
                #6  0x00007f9c940a981c n/a (libpulsecommon-11.1.so)
                #7  0x00007f9cb3ab208a start_thread (libpthread.so.0)
                #8  0x00007f9cb37ea1bf __clone (libc.so.6)
                
                Stack trace of thread 6786:
                #0  0x00007f9cb3ab838d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007f9caac24465 n/a (libmozjs-52.so.0)
                #2  0x00007f9caac246b5 n/a (libmozjs-52.so.0)
                #3  0x00007f9cab0222e5 n/a (libmozjs-52.so.0)
                #4  0x00007f9cab042ca2 n/a (libmozjs-52.so.0)
                #5  0x00007f9cb3ab208a start_thread (libpthread.so.0)
                #6  0x00007f9cb37ea1bf __clone (libc.so.6)
                
                Stack trace of thread 6773:
                #0  0x00007f9cb37dfcbb __poll (libc.so.6)
                #1  0x00007f9cb29f6ed3 n/a (libglib-2.0.so.0)
                #2  0x00007f9cb29f6fae g_main_context_iteration (libglib-2.0.so.0)
                #3  0x00007f9c9cc7fb0e n/a (libdconfsettings.so)
                #4  0x00007f9cb29eb1eb n/a (libglib-2.0.so.0)
                #5  0x00007f9cb3ab208a start_thread (libpthread.so.0)
                #6  0x00007f9cb37ea1bf __clone (libc.so.6)
                
                Stack trace of thread 6784:
                #0  0x00007f9cb3ab838d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007f9caac24465 n/a (libmozjs-52.so.0)
                #2  0x00007f9caac246b5 n/a (libmozjs-52.so.0)
                #3  0x00007f9cab0222e5 n/a (libmozjs-52.so.0)
                #4  0x00007f9cab042ca2 n/a (libmozjs-52.so.0)
                #5  0x00007f9cb3ab208a start_thread (libpthread.so.0)
                #6  0x00007f9cb37ea1bf __clone (libc.so.6)
                
                Stack trace of thread 6781:
                #0  0x00007f9cb3ab838d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007f9caac24465 n/a (libmozjs-52.so.0)
                #2  0x00007f9caac246b5 n/a (libmozjs-52.so.0)
                #3  0x00007f9cab0222e5 n/a (libmozjs-52.so.0)
                #4  0x00007f9cab042ca2 n/a (libmozjs-52.so.0)
                #5  0x00007f9cb3ab208a start_thread (libpthread.so.0)
                #6  0x00007f9cb37ea1bf __clone (libc.so.6)
                
                Stack trace of thread 6829:
                #0  0x00007f9cb37e4bb9 syscall (libc.so.6)
                #1  0x00007f9cb2a1ef2f g_cond_wait_until (libglib-2.0.so.0)
                #2  0x00007f9cb2a11393 n/a (libglib-2.0.so.0)
                #3  0x00007f9cb2a1155e g_async_queue_timeout_pop (libglib-2.0.so.0)
                #4  0x00007f9cb29e6041 n/a (libglib-2.0.so.0)
                #5  0x00007f9cb29eb1eb n/a (libglib-2.0.so.0)
                #6  0x00007f9cb3ab208a start_thread (libpthread.so.0)
                #7  0x00007f9cb37ea1bf __clone (libc.so.6)
                
                Stack trace of thread 6782:
                #0  0x00007f9cb3ab838d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007f9caac24465 n/a (libmozjs-52.so.0)
                #2  0x00007f9caac246b5 n/a (libmozjs-52.so.0)
                #3  0x00007f9cab0222e5 n/a (libmozjs-52.so.0)
                #4  0x00007f9cab042ca2 n/a (libmozjs-52.so.0)
                #5  0x00007f9cb3ab208a start_thread (libpthread.so.0)
                #6  0x00007f9cb37ea1bf __clone (libc.so.6)
                
                Stack trace of thread 6788:
                #0  0x00007f9cb3ab838d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007f9caac24465 n/a (libmozjs-52.so.0)
                #2  0x00007f9caac246b5 n/a (libmozjs-52.so.0)
                #3  0x00007f9cab0222e5 n/a (libmozjs-52.so.0)
                #4  0x00007f9cab042ca2 n/a (libmozjs-52.so.0)
                #5  0x00007f9cb3ab208a start_thread (libpthread.so.0)
                #6  0x00007f9cb37ea1bf __clone (libc.so.6)
                
                Stack trace of thread 6780:
                #0  0x00007f9cb3ab838d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007f9caac24465 n/a (libmozjs-52.so.0)
                #2  0x00007f9caac246b5 n/a (libmozjs-52.so.0)
                #3  0x00007f9cab0222e5 n/a (libmozjs-52.so.0)
                #4  0x00007f9cab042ca2 n/a (libmozjs-52.so.0)
                #5  0x00007f9cb3ab208a start_thread (libpthread.so.0)
                #6  0x00007f9cb37ea1bf __clone (libc.so.6)

It seems to be related to extensions. If I disable all my extensions, I don't see the crash anymore.

I had the following ones on at the time (to the best of my memory)
Dash to dock
Multi-monitors add-on
Put windows
Removeable drive menu
Steal my focus
Topicons

My crash repro is simply logging in my non-root account. I feel I can repro this pretty reliably. If you post some info on how to use use the tools above (e.g valgrind,gjs_dumpstack) with gnome-shell, I'll try to get some dumps.

Another datapoint: Put Windows seems to not be updated for 3.26 and throws the following error:

Error: Requiring Wnck, version none: Typelib file for namespace 'Wnck' (any version) not found


Stack trace:
  @/home/pedrum/.local/share/gnome-shell/extensions/putWindow@clemens.lab21.org/prefs.js:7:7
  Application<._getExtensionPrefsModule@resource:///org/gnome/shell/extensionPrefs/main.js:75:13
  wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
  Application<._selectExtension@resource:///org/gnome/shell/extensionPrefs/main.js:90:31
  wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
  Application<._onCommandLine@resource:///org/gnome/shell/extensionPrefs/main.js:246:17
  wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
  main@resource:///org/gnome/shell/extensionPrefs/main.js:402:5
  @<main>:1:43

Arch appears to have released a fix.

pedrum@gmail.com: That seems unrelated to this problem. Please open a gnome-shell bug report.

@pedrum Maybe I experience the same as you.. I just opened this bug report:
https://bugzilla.gnome.org/show_bug.cgi?id=789070

Closing this bug report in order to clean up the backlog, in preparation for migration to GitLab. I'm not sure whether this is still happening, I haven't had any crash since releasing 1.48.7 (although it was quite rare for me in the first place as well)

Please feel free to reopen this bug report on GitLab if you can provide
- reliable way to force a crash
- valgrind trace
- gjs_dumpstack()

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