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 317246 - GLib misuses G_GNUC_CONST in get_type() functions
GLib misuses G_GNUC_CONST in get_type() functions
Status: RESOLVED DUPLICATE of bug 65041
Product: glib
Classification: Platform
Component: gobject
2.8.x
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2005-09-26 14:04 UTC by Andy Wingo
Modified: 2005-09-26 14:56 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Andy Wingo 2005-09-26 14:04:19 UTC
Hi,

Just ran into a problem in my program where it launches many threads, which make
values and pass them to a function that compares their types against a number of
predefined types. Included in those was G_TYPE_DATE from GLib 2.8.

Since the GDate type had not been initialized before, it tried to register it
from multiple threads at the same time which caused my program to crash.

Knowing these types are registered at runtime, the obvious thing to do is to
have an initialization function in my program which does g_date_get_type(). But
that can't work in the obvious way because these functions are declared
G_GNUC_CONST, which means the compiler is free not to call it!

See also http://wingolog.org/archives/2005/03/24/98, an earlier runin with the
same issue, but in GStreamer instead (so I controlled the solution ;)

Fundamental problem is these functions are not __const__ because they call
non-__const__ functions (register_type, which modifies global state). See the
gcc info for more about this. Suggest removing the G_GNUC_CONST declaration.
Comment 1 Matthias Clasen 2005-09-26 14:56:32 UTC
You need to use a volatile GType if you want to force initialization.
The (lack of) thread-safety of get type functions is discussed in bug 65041,
Their (lack of) constness is discussed e.g. in bug 64994.

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