From: Michal Privoznik <mprivozn@redhat.com>
Date: Wed, 21 Jun 2023 06:56:54 +0000 (+0200)
Subject: virGlobalInit: Make glib init its own global state
X-Git-Url: http://xenbits.xensource.com/gitweb?a=commitdiff_plain;h=1dddd444519717c785a9fd93f393c3313c87c342;p=libvirt.git

virGlobalInit: Make glib init its own global state

This should not be needed, but here's what's happening:
virStrToLong_*() family of functions was switched from strtol*()
to g_ascii_strtol*() in order to handle corner cases on Windows
(most notably parsing hex numbers with base=0) - see
v9.4.0-61-g2ed41d7cd9. But what we did not realize back then, is
the fact that g_ascii_strtol*() family has their own global lock
rendering virStrToLong_*() function unsafe between fork() +
exec(). Worse, if one of the threads has to wait for the lock (or
on its corresponding condition), then errno is mangled and
g_ascii_strtol*() signals an error, even though there's no error.

Read more here:

  https://gitlab.gnome.org/GNOME/glib/-/issues/3034

Nevertheless, if we make glib init the g_ascii_strtol*() global
state (by calling one function from g_ascii_strtol*() family),
then there shouldn't be any congestion on the lock and thus no
errno mangling.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
---

diff --git a/src/libvirt.c b/src/libvirt.c
index 2e470adf98..69d5b13bff 100644
--- a/src/libvirt.c
+++ b/src/libvirt.c
@@ -214,6 +214,14 @@ virGlobalInit(void)
     if (virErrorInitialize() < 0)
         goto error;
 
+    /* Make glib initialize its own global state. See more:
+     *
+     *   https://gitlab.gnome.org/GNOME/glib/-/issues/3034
+     *
+     * TODO: Remove ASAP.
+     */
+    g_ascii_strtoull("0", NULL, 0);
+
     virFileActivateDirOverrideForLib();
 
     if (getuid() != geteuid() ||