GNOME Bugzilla – Bug 781975
Under Wayland, Totem spawns a new window without controls for some files and then gnome-shell crashes
Last modified: 2017-05-11 01:11:49 UTC
Created attachment 350764 [details] Screenshot of activities overview after trying to play the video I was trying to play sample videos from http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5 using Totem (adding them to library first and then clicking the thumbnails inside totem itself), and with most of them (especially the gp3 one) what happened was that a new window got spawned with no controls, the video played for a couple of seconds and then it crashed (see the screenshot). I was not able to close any of the windows from the activities overview. Sometimes after a while GNOME detected that the application stopped working and gave me the option to force-quit, but most of the time it actually crashed the whole desktop and I was kicked out to GDM. Works under X11.
I'm guessing this is an old clutter-gtk/clutter-gst or an old gnome-shell. Which versions of those packages are you using?
I'm using a fully upgraded Antergos install: clutter-gtk 1.8.2 clutter-gst 3.0.24 gnome-shell 3.24.1+2+g45c2627d4
Which graphics card is this with, and with which drivers? (open source or proprietary NVidia or ATI for example)
It's happening on a Lenovo T420 with integrated Intel HD3000 (Sandy Bridge) graphics: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller, Kernel driver in use: i915 I'm using modesetting DDX driver if that's important.
I have no idea what the problem is, sorry.
I've been seeing this with a freshly built 3.24 jhbuild moduleset (the totem bits with --ignore-suggests). This does not happen on my system f26 3.24 totem. After a few tests with LD_PRELOAD=/usr/lib64/xxx jhbuild run totem pointing to changes in clutter, and a git bisect, I found out that reverting https://git.gnome.org/browse/clutter/commit/?id=ffa7aa95d8ec62efbbc20e5aacc29d52555f3145 "gdk: stage: Use gdk for the Wayland subsurface" is the commit which introduced this bug. I reproduce by: - clicking on a video (not sure its type matters, I'm testing with youtube videos which error out with 'forbidden' before playing back anything, but this happens too with videos playing back fine) - going back to the overview - clicking on a video (the same or a different one, in my tests the video was giving an error before playing back) -> the video plays back in a separate window, but interactions still happen through the main totem window On a side note, while experimenting with this, gnome-shell crashed very often when the bug reproduced, not fully sure these 2 things are related though.
totembugreport, which version of clutter are you running with?
(In reply to Christophe Fergeau from comment #6) > I've been seeing this with a freshly built 3.24 jhbuild moduleset (the totem > bits with --ignore-suggests). This does not happen on my system f26 3.24 > totem. > [...] Yeah, I can see that as well.
Any possibility to get a backtrace of the gnome-shell crash? A log output of running WAYLAND_DEBUG=1 totem >& totem.log and reproducing the issue would possibly help too.
Sure, coredumpctl ftw! This seems to be happening in js-related code, do you need the WAYLAND_DEBUG trace ?
+ Trace 237436
Thread 1 (Thread 0x7f3e18816f80 (LWP 29811))
It's just the unrealize() case not being well handled, I do have a fix :)
Created attachment 351432 [details] [review] [PATCH] gdk: stage: destroy and clear subsurface on unrealize() When using a gdk subsurface, destroy it on clutter_stage_gdk_unrealize() to avoid keeping around an old existing subsurface pointing to a parent surface which might be gone.
Review of attachment 351432 [details] [review]: Looks good to me.
Comment on attachment 351432 [details] [review] [PATCH] gdk: stage: destroy and clear subsurface on unrealize() attachment 351432 [details] [review] has bee npushed to git master as commit 03c7b02 - gdk: stage: destroy and clear subsurface on unrealize()
Patch has been pushed git master for clutter, please reopen if the issue remains :)
(In reply to Christophe Fergeau from comment #10) > Sure, coredumpctl ftw! This seems to be happening in js-related code, do you > need the WAYLAND_DEBUG trace ? I reckon we should follow-up the gnome-shell issue in a separate dedicated bug.
(In reply to Olivier Fourdan from comment #16) > (In reply to Christophe Fergeau from comment #10) > > Sure, coredumpctl ftw! This seems to be happening in js-related code, do you > > need the WAYLAND_DEBUG trace ? > > I reckon we should follow-up the gnome-shell issue in a separate dedicated > bug. I suspect its a gjs issue, rather than a gnome-shell issue.
Philip, does the backtrace in comment 10 look familiar? It seems to crash during GC. (This bug is not only about that, so asking if it should be reported or is already known).
This may or may not be a GJS crash, but in any case it's not one that I've seen before. If the crash seems to bring down gnome-shell without any action causing it, then maybe bug 781799 is the best place for it.
It brings down gnome-shell, but I'm usually interacting with it when this happens.
(In reply to Philip Chimento from comment #19) > This may or may not be a GJS crash, but in any case it's not one that I've > seen before. If the crash seems to bring down gnome-shell without any action > causing it, then maybe bug 781799 is the best place for it. As far as I can tell, the crash happens during garbage collection, and doesn't leave mozjs/gjs/glib after the JS_MaybeGC(context). It seems to be going ibus panel -> emit signal -> invoke javascript closure -> GC -> *crash* I'll attach the backtrace to bug 781799 for now.