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 780815 - Possible incompatibility of GTK 3.22 with Boehm GC (because of threads)
Possible incompatibility of GTK 3.22 with Boehm GC (because of threads)
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: .General
3.22.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2017-04-01 17:48 UTC by Basile Starynkevitch
Modified: 2018-05-02 18:20 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Basile Starynkevitch 2017-04-01 17:48:47 UTC
http://stackoverflow.com/q/43141659/841108 is a better description. I'm summarizing it here.

(Plartform: Debian/Sid/x86-64; GTK is 3.22.11, Glib is 2.50.3)

I'm not sure of a bug. Perhaps it just requires a documentation clarification.

Boehm's GC https://www.hboehm.info/gc/ is requiring that every thread using it should be created with GC_pthread_create....

But it looks that GTK is creating threads (e.g. for DBus stuff, or GtkTextView stuff) "behind my back".

Can I be sure that if I correctly follow the GTK coding rule of only having GTK code called from the main thread, the internal threads never call my routines (e.g. GTK signal slots or GTK methods that I have provided by subclassing GTK classes) which are using GC_malloc ?

struct GMemVTable is deprecated....

Thanks for reading.

Basile Starynkevitch (France) == http://starynkevitch.net/Basile/
email basile at starynkevitch dot net
Comment 1 Emmanuele Bassi (:ebassi) 2017-04-01 17:54:33 UTC
All GTK+ API will always be called in the main thread - i.e. the one that called gtk_init() and is spinning the default main context. GTK+ would not work any other way, and any use of GTK+ API outside of the main thread results in undefined behaviour.

The documentation for GTK+ specifies this here: https://developer.gnome.org/gdk3/stable/gdk3-Threads.html
Comment 2 Emmanuele Bassi (:ebassi) 2017-04-01 17:56:07 UTC
Even if GTK+ creates a separate thread internally, all user callbacks will be invoked in the main thread.
Comment 3 Matthias Clasen 2017-04-01 18:04:50 UTC
GTK+ does not create any threads behind your back.

GLib does create threads for its own purposes. They are created with pthread_create.

#define pthread_create GC_pthread_create

is simply not an adequate solution
Comment 4 Basile Starynkevitch 2017-04-02 16:07:30 UTC
A possible workaround could be to add some hook to replace pthread_create by GC_pthread_create (or something else).

Actually, what is really needed by Boehm's GC is to have GC_register_my_thread called early in the new thread. See https://github.com/ivmai/bdwgc/blob/master/include/gc.h#L1393 for more. Adding some hook to permit this could be enough.
Comment 5 Basile Starynkevitch 2017-04-02 16:11:57 UTC
BTW, I just compiled gtk+-3.22.11/examples/application9/ code with -g, and run it in the debugger. I did add a break point on pthread_create. It is reached:

(gdb) bt
  • #0 pthread_create
    from /lib/x86_64-linux-gnu/libpthread.so.0
  • #1 ??
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #2 ??
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #3 g_thread_new
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #4 ??
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #5 g_task_get_type
    from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
  • #6 ??
    from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
  • #7 ??
    from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
  • #8 g_bus_get_sync
    from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
  • #9 ??
    from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
  • #10 g_application_register
    from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
  • #11 ??
    from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
  • #12 g_application_run
    from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
  • #13 __libc_start_main
    from /lib/x86_64-linux-gnu/libc.so.6
  • #14 _start

but the thread word does not appear in any *.[ch] file. This is what I say that GTK is creating threads behind my back. That application9 code does not mention threads.
Comment 6 Basile Starynkevitch 2017-04-02 16:28:42 UTC
Perhaps a few sentences of additional documentation (which could go with that of g_mem_gc_friendly ...) might be enough: just tell in what cases (perhaps subclassing GtkApplication ??) user provided code (e.g. calling GC_malloc) is called outside of the main thread.
Comment 7 GNOME Infrastructure Team 2018-05-02 18:20:28 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/796.