Re: [PATCH 3/3] virGlobalInit: Make glib init its own global state

On Wed, Jun 21, 2023 at 5:30 PM Daniel P. Berrangé <berrange(a)redhat.com&gt; wrote: > > On Wed, Jun 21, 2023 at 04:09:11PM +0200, Michal Privoznik wrote: > > 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(a)redhat.com&gt; > > --- > > src/libvirt.c | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > Reviewed-by: Daniel P. Berrangé <berrange(a)redhat.com&gt; Thanks, let me push this one, as it fixes both problems (daedlock and string parse problem) and work on the other two next week as I'm going AFK for the rest of the week. Jirka plans to freeze on Tuesday next week but after this patch, close_range()/closefrom() is not that critical.