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 750386 - Race condition in g_io_condition_get_type
Race condition in g_io_condition_get_type
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gobject
2.45.x
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2015-06-04 09:30 UTC by Stefan Ekenberg
Modified: 2015-06-05 02:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch (1.59 KB, patch)
2015-06-04 09:30 UTC, Stefan Ekenberg
committed Details | Review

Description Stefan Ekenberg 2015-06-04 09:30:31 UTC
Created attachment 304571 [details] [review]
Patch

I have encountered the print

  GLib-GObject-WARNING **: cannot register existing type 'GIOCondition'

and identified a race condition in function g_io_condition_get_type. There is no locking between the check to see if 'etype' has been initialized

  if (etype == 0)

and the registration of the 'GIOCondition' type

  etype = g_flags_register_static ("GIOCondition", values);

This means that there is a race condition where two concurrent threads could pass its execution beyond the if-statement and thereby result in multiple threads attempting to register "GIOCondition". There are two possible outcomes of this:

1) Both threads are able to execute g_flags_register_static() and type 'GIOCondition' is registered twice. The result from the second thread will then be used as 'etype'. This is the less severe case.

2) First thread executes entire function g_flags_register_static(). The second thread will then fail at check_type_name_I() (in function g_flags_register_static) since 'GIOCondition' has in that case already been registered. Static variable 'etype' will then be set to 0 by that thread, and the function will therefore also return the value 0 as GType. This is what I encountered and is the scenario which triggers the aforementioned print.

I have attached a patch which solves this race condition using the g_once_init_enter()/g_once_init_leave() mechanism.