After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 781975 - Under Wayland, Totem spawns a new window without controls for some files and then gnome-shell crashes
Under Wayland, Totem spawns a new window without controls for some files and ...
Status: RESOLVED FIXED
Product: clutter
Classification: Platform
Component: wayland
unspecified
Other Linux
: Normal major
: ---
Assigned To: clutter-maint
clutter-maint
Depends on:
Blocks:
 
 
Reported: 2017-04-30 14:07 UTC by totembugreport
Modified: 2017-05-11 01:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screenshot of activities overview after trying to play the video (567.31 KB, image/png)
2017-04-30 14:07 UTC, totembugreport
  Details
[PATCH] gdk: stage: destroy and clear subsurface on unrealize() (1.20 KB, patch)
2017-05-09 13:03 UTC, Olivier Fourdan
committed Details | Review

Description totembugreport 2017-04-30 14:07:08 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.
Comment 1 Bastien Nocera 2017-05-02 10:17:27 UTC
I'm guessing this is an old clutter-gtk/clutter-gst or an old gnome-shell. Which versions of those packages are you using?
Comment 2 totembugreport 2017-05-02 16:50:31 UTC
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
Comment 3 Bastien Nocera 2017-05-02 17:15:20 UTC
Which graphics card is this with, and with which drivers? (open source or proprietary NVidia or ATI for example)
Comment 4 totembugreport 2017-05-02 17:25:36 UTC
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.
Comment 5 Bastien Nocera 2017-05-03 10:51:54 UTC
I have no idea what the problem is, sorry.
Comment 6 Christophe Fergeau 2017-05-09 08:04:44 UTC
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.
Comment 7 Christophe Fergeau 2017-05-09 08:13:00 UTC
totembugreport, which version of clutter are you running with?
Comment 8 Olivier Fourdan 2017-05-09 11:29:48 UTC
(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.
Comment 9 Jonas Ådahl 2017-05-09 12:33:34 UTC
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.
Comment 10 Christophe Fergeau 2017-05-09 12:46:41 UTC
Sure, coredumpctl ftw! This seems to be happening in js-related code, do you need the WAYLAND_DEBUG trace ?

Thread 1 (Thread 0x7f3e18816f80 (LWP 29811))

  • #0 g_type_check_instance_cast
    at gtype.c line 4052
  • #1 GjsMaybeOwned<JS::Value>::teardown_rooting()
    at gjs/jsapi-util-root.h line 156
  • #2 GjsMaybeOwned<JS::Value>::reset()
    at gjs/jsapi-util-root.h line 270
  • #3 object_instance_finalize(JSFreeOp*, JSObject*)
    at gi/object.cpp line 1626
  • #4 JSObject::finalize(js::FreeOp*)
    at /usr/src/debug/mozilla-esr38/js/src/jsobjinlines.h line 42
  • #5 js::gc::Arena::finalize<JSObject>(js::FreeOp*, js::gc::AllocKind, unsigned long)
    at /usr/src/debug/mozilla-esr38/js/src/jsgc.cpp line 497
  • #6 FinalizeTypedArenas<JSObject>
    at /usr/src/debug/mozilla-esr38/js/src/jsgc.cpp line 557
  • #7 FinalizeArenas(js::FreeOp *, js::gc::ArenaHeader **, js::gc::SortedArenaList &, enum AllocKind, struct SliceBudget &, js::gc::ArenaLists::KeepArenasEnum)
    at /usr/src/debug/mozilla-esr38/js/src/jsgc.cpp line 600
  • #8 js::gc::ArenaLists::forceFinalizeNow(js::FreeOp*, js::gc::AllocKind, js::gc::ArenaLists::KeepArenasEnum, js::gc::ArenaHeader**)
    at /usr/src/debug/mozilla-esr38/js/src/jsgc.cpp line 2758
  • #9 js::gc::ArenaLists::finalizeNow(js::FreeOp*, js::gc::AllocKind, js::gc::ArenaLists::KeepArenasEnum, js::gc::ArenaHeader**)
    at /usr/src/debug/mozilla-esr38/js/src/jsgc.cpp line 2741
  • #10 js::gc::ArenaLists::queueForegroundObjectsForSweep(js::FreeOp*)
    at /usr/src/debug/mozilla-esr38/js/src/jsgc.cpp line 2876
  • #11 js::gc::GCRuntime::beginSweepingZoneGroup()
    at /usr/src/debug/mozilla-esr38/js/src/jsgc.cpp line 5069
  • #12 js::gc::GCRuntime::beginSweepPhase(bool)
    at /usr/src/debug/mozilla-esr38/js/src/jsgc.cpp line 5164
  • #13 js::gc::GCRuntime::incrementalCollectSlice(js::SliceBudget&, JS::gcreason::Reason)
    at /usr/src/debug/mozilla-esr38/js/src/jsgc.cpp line 5889
  • #14 js::gc::GCRuntime::gcCycle(bool, js::SliceBudget&, JS::gcreason::Reason)
    at /usr/src/debug/mozilla-esr38/js/src/jsgc.cpp line 6076
  • #15 js::gc::GCRuntime::collect(bool, js::SliceBudget, JS::gcreason::Reason)
    at /usr/src/debug/mozilla-esr38/js/src/jsgc.cpp line 6190
  • #16 js::gc::GCRuntime::startGC(JSGCInvocationKind, JS::gcreason::Reason, long)
    at /usr/src/debug/mozilla-esr38/js/src/jsgc.cpp line 6259
  • #17 js::gc::GCRuntime::maybePeriodicFullGC()
    at /usr/src/debug/mozilla-esr38/js/src/jsgc.cpp line 3246
  • #18 JS_MaybeGC(JSContext*)
    at /usr/src/debug/mozilla-esr38/js/src/jsapi.cpp line 1341
  • #19 gjs_schedule_gc_if_needed(JSContext*)
    at gjs/jsapi-util.cpp line 844
  • #20 gjs_call_function_value(JSContext*, JS::HandleObject, JS::HandleValue, JS::HandleValueArray const&, JS::MutableHandleValue)
    at gjs/jsapi-util.cpp line 719
  • #21 gjs_closure_invoke(GClosure*, JS::HandleValueArray const&, JS::MutableHandleValue)
    at gi/closure.cpp line 229
  • #22 closure_marshal(GClosure*, GValue*, guint, GValue const*, gpointer, gpointer)
    at gi/value.cpp line 273
  • #26 <emit signal ??? on instance 0x556510f60490 [IBusPanelService]>
    at gsignal.c line 3447
  • #27 ibus_panel_service_service_method_call
    at ibuspanelservice.c line 1064
  • #28 call_in_idle_cb
    at gdbusconnection.c line 4850
  • #29 g_idle_dispatch
    at gmain.c line 5554
  • #30 g_main_dispatch
    at gmain.c line 3212
  • #31 g_main_context_dispatch
    at gmain.c line 3865
  • #32 g_main_context_iterate
    at gmain.c line 3938
  • #33 g_main_loop_run
    at gmain.c line 4134
  • #34 meta_run
    at core/main.c line 646
  • #35 main
    at main.c line 454

Comment 11 Olivier Fourdan 2017-05-09 12:54:28 UTC
It's just the unrealize() case not being well handled, I do have a fix :)
Comment 12 Olivier Fourdan 2017-05-09 13:03:42 UTC
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.
Comment 13 Emmanuele Bassi (:ebassi) 2017-05-09 13:04:34 UTC
Review of attachment 351432 [details] [review]:

Looks good to me.
Comment 14 Olivier Fourdan 2017-05-09 13:07:10 UTC
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()
Comment 15 Olivier Fourdan 2017-05-09 13:08:01 UTC
Patch has been pushed git master for clutter, please reopen if the issue remains :)
Comment 16 Olivier Fourdan 2017-05-09 13:10:03 UTC
(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.
Comment 17 Jonas Ådahl 2017-05-09 15:30:01 UTC
(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.
Comment 18 Jonas Ådahl 2017-05-10 08:12:26 UTC
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).
Comment 19 Philip Chimento 2017-05-10 15:16:03 UTC
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.
Comment 20 Christophe Fergeau 2017-05-10 15:31:00 UTC
It brings down gnome-shell, but I'm usually interacting with it when this happens.
Comment 21 Jonas Ådahl 2017-05-11 01:11:49 UTC
(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.