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 744082 - Dead lock when exiting gjs
Dead lock when exiting gjs
Status: RESOLVED DUPLICATE of bug 742065
Product: clutter
Classification: Platform
Component: general
1.20.x
Other Linux
: Normal normal
: ---
Assigned To: clutter-maint
clutter-maint
Depends on:
Blocks:
 
 
Reported: 2015-02-06 04:29 UTC by Lionel Landwerlin
Modified: 2015-02-06 10:35 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Lionel Landwerlin 2015-02-06 04:29:59 UTC
Here is gjs script :


const Clutter = imports.gi.Clutter;
const Mainloop = imports.mainloop;

Clutter.init(null, null);

let stage = new Clutter.Stage({});
stage.show();

Mainloop.timeout_add(50, function() { Clutter.main_quit(); });

Clutter.main();


This triggers a deadlock here :

Program received signal SIGINT, Interrupt.
syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
38	../sysdeps/unix/sysv/linux/x86_64/syscall.S: No such file or directory.
(gdb) bt
  • #0 syscall
    at ../sysdeps/unix/sysv/linux/x86_64/syscall.S line 38
  • #1 g_mutex_lock_slowpath
    at gthread-posix.c line 1308
  • #2 clutter_clock_prepare
    at clutter-master-clock.c line 508
  • #3 g_main_context_prepare
    at gmain.c line 3410
  • #4 g_main_context_iterate
    at gmain.c line 3788
  • #5 g_main_context_pending
    at gmain.c line 3834
  • #6 gjs_object_prepare_shutdown
    at gi/object.cpp line 1126
  • #7 gjs_context_dispose
    at gjs/context.cpp line 359
  • #8 g_object_unref
    at gobject.c line 3133
  • #9 main
    at gjs/console.cpp line 154



This pretty much prevents a Clutter app from exiting if using gjs. The equivalent in written using Gtk works.
What could be done about it?

Removing the master clock's source? Release the global lock?
Comment 1 Lionel Landwerlin 2015-02-06 10:12:49 UTC
Apparently hiding the stage before returning back to the mainloop works around this problem.
Comment 2 Emmanuele Bassi (:ebassi) 2015-02-06 10:34:25 UTC
there's bug 742065 already open about this.

it's weird that this only happens with GJS: PyGI does not have any issue with it, so I guess it's just a threading/GC issue.

we could conceivably use a destructor to unref the backend and context, which would also take care of the master clock; I'm not entirely sure this would work, though.
Comment 3 Emmanuele Bassi (:ebassi) 2015-02-06 10:35:01 UTC

*** This bug has been marked as a duplicate of bug 742065 ***