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 661421 - Applications fail to initialize on GNU Hurd - commit
Applications fail to initialize on GNU Hurd - commit
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
2.29.x
Other GNU Hurd
: Normal major
: ---
Assigned To: gtkdev
gtkdev
: 668738 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-10-11 00:49 UTC by Stephen Gilles
Modified: 2012-01-26 14:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GDB output (3.35 KB, text/plain)
2011-10-11 12:56 UTC, Stephen Gilles
  Details
GDB log, irssi+GLib2.30.0 (with trace symbols) (1.59 KB, application/octet-stream)
2011-10-11 18:02 UTC, Stephen Gilles
  Details
Simplify checks for CLOCK_MONOTONIC (4.63 KB, patch)
2011-10-11 19:40 UTC, Dan Winship
committed Details | Review
diff -w version, since it's mostly reindentation (2.30 KB, patch)
2011-10-11 19:40 UTC, Dan Winship
accepted-commit_now Details | Review

Description Stephen Gilles 2011-10-11 00:49:19 UTC
Steps to reproduce:

 - Using Arch Hurd, build any version of GLib past commit c0eb77bfc "unix signal watch: make API match other sources"   (Version 2.30.x, 2.29.92, etc.  I have tagged this bug with version 2.29.x since that is where the commit appeared.)
 - Launch irssi, gtk3-demo, etc.  
 - The following message appears:
    Glib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 - Revert GLib to version 2.29.18-1
 - Launch irssi, gtk3-demo, etc.  Applications run normally.

Git bisect reveals that the issue appeared in commit c0eb77bfc.  Reverting the offending commit from current source appears to be complicated, as several other commits have sprung up around it.  I am attempting to scan enough of the code to intelligently make changes, but unfortunately I cannot offer a fix yet.

 - prce is version 8.12
 - libffi is version 3.0.10
 - glibc is version 2.14 (if it matters)

Note: I have tested this with programs (specifically, irssi 0.8.15) built both against GLib2.30.0 and GLib2.29.18.  In each case, behavior was identical: GLib2.29.18 allowed programs' initialization and launch, GLib 2.30.0 did not.  I can provide more package details or configuration if requested.

I apologize if I have been unclear or if I have left out anything.  Please let me know if more information is required.
Comment 1 Matthias Clasen 2011-10-11 11:40:23 UTC
One helpful thing to do would be to find out which code is producing the warning you are seeing.

Running the program under gdb and breaking on g_logv should let you get a backtrace.
Comment 2 Stephen Gilles 2011-10-11 12:52:20 UTC
Output follows for irssi and gtk3-demo.

---------------------------------------
Reading symbols from /bin/irssi...(no debugging symbols found)...done.
(gdb) break g_logv
Function "g_logv" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (g_logv) pending.
(gdb) run
Starting program: /bin/irssi 
[New Thread 2003.5]

Breakpoint 1, 0x01260b16 in g_logv () from /lib/libglib-2.0.so.0
(gdb) bt
  • #0 g_logv
    from /lib/libglib-2.0.so.0
  • #1 g_log
    from /lib/libglib-2.0.so.0
  • #2 g_return_if_fail_warning
    from /lib/libglib-2.0.so.0
  • #3 g_once_init_leave
    from /lib/libglib-2.0.so.0
  • #4 g_get_monotonic_time
    from /lib/libglib-2.0.so.0
  • #5 g_timeout_source_new
    from /lib/libglib-2.0.so.0
  • #6 g_timeout_add_full
    from /lib/libglib-2.0.so.0
  • #7 g_timeout_add
    from /lib/libglib-2.0.so.0
  • #8 settings_init
  • #9 core_init
  • #10 main
  • #0 g_logv
    from /lib/libglib-2.0.so.0
  • #1 g_log
    from /lib/libglib-2.0.so.0
  • #2 g_return_if_fail_warning
    from /lib/libglib-2.0.so.0
  • #3 g_once_init_leave
    from /lib/libglib-2.0.so.0
  • #4 g_get_monotonic_time
    from /lib/libglib-2.0.so.0
  • #5 g_timer_new
    from /lib/libglib-2.0.so.0
  • #6 ??
    from /lib/libgtk-3.so.0
  • #7 ??
    from /lib/libgtk-3.so.0
  • #8 ??
    from /lib/libgtk-3.so.0
  • #9 ??
    from /lib/libgtk-3.so.0
  • #10 ??
    from /lib/libgtk-3.so.0
  • #11 ??
    from /lib/libgtk-3.so.0
  • #12 ??
    from /lib/libgtk-3.so.0
  • #13 ??
    from /lib/libgtk-3.so.0
  • #14 ??
    from /lib/libgtk-3.so.0
  • #15 ??
    from /lib/libgtk-3.so.0
  • #16 ??
    from /lib/libgtk-3.so.0
  • #17 ??
    from /lib/libgtk-3.so.0
  • #18 gtk_widget_get_preferred_size
    from /lib/libgtk-3.so.0
  • #19 ??
    from /lib/libgtk-3.so.0
  • #20 ??
    from /lib/libgtk-3.so.0
  • #21 g_cclosure_marshal_VOID__VOID
    from /lib/libgobject-2.0.so.0
  • #22 ??
    from /lib/libgobject-2.0.so.0
  • #23 g_closure_invoke
    from /lib/libgobject-2.0.so.0
  • #24 ??
    from /lib/libgobject-2.0.so.0
  • #25 g_signal_emit_valist
    from /lib/libgobject-2.0.so.0
  • #26 g_signal_emit
    from /lib/libgobject-2.0.so.0
  • #27 gtk_widget_show
    from /lib/libgtk-3.so.0
  • #28 ??
    from /lib/libgtk-3.so.0
  • #29 gtk_widget_show_all
    from /lib/libgtk-3.so.0
  • #30 main
Continuing.

(gtk3-demo:2291): GLib-CRITICAL **: g_once_init_leave: assertion nitialization_value != 0' failed

...
Comment 3 Stephen Gilles 2011-10-11 12:56:35 UTC
Created attachment 198784 [details]
GDB output

This is what I intended to paste into reply #2.
Comment 4 André Klapper 2011-10-11 13:00:07 UTC
That stacktrace is missing any debug symbols, so quite useless...
Comment 5 Stephen Gilles 2011-10-11 18:02:09 UTC
Created attachment 198804 [details]
GDB log, irssi+GLib2.30.0 (with trace symbols)

Right.  This version should have correct tracing.
Comment 6 Dan Winship 2011-10-11 18:56:13 UTC
oh... looks like either CLOCK_MONOTONIC or CLOCK_REALTIME has the value 0 on Hurd, thus angering the g_once_init_leave() call
Comment 7 Dan Winship 2011-10-11 18:57:18 UTC
oops, I added Ryan to the cc, but now that I think about it, that code is my fault :-}
Comment 8 Dan Winship 2011-10-11 19:40:03 UTC
Created attachment 198806 [details] [review]
Simplify checks for CLOCK_MONOTONIC

Remove the complicated configure-time and runtime checks, and just use
CLOCK_MONOTONIC if it's defined.

=====

This incorporates suggestions from bug 661386 as well
Comment 9 Dan Winship 2011-10-11 19:40:30 UTC
Created attachment 198807 [details] [review]
diff -w version, since it's mostly reindentation
Comment 10 Stephen Gilles 2011-10-11 20:16:39 UTC
With this patch, 2.30.0 works as expected.  I'll go ahead and mark this as fixed if that's all right with everyone.

Thank you!
Comment 11 André Klapper 2011-10-11 20:20:25 UTC
Patch has not been committed yet as far as I understand => reopening.
Comment 12 Matthias Clasen 2011-10-12 00:29:39 UTC
Review of attachment 198807 [details] [review]:

Looks fine to me, if it works without the extra sysconf cargo culting...
Comment 13 Dan Winship 2011-10-12 13:00:13 UTC
Attachment 198806 [details] pushed as 71cf70b - Simplify checks for CLOCK_MONOTONIC
Comment 14 Dan Winship 2012-01-26 14:44:59 UTC
*** Bug 668738 has been marked as a duplicate of this bug. ***