This seems to consistently make anaconda crash on startup - same failure on Workstation live, KDE live, Everything netinst, and Silverblue installer image.
Looking at the diff from 2.76.4 to 2.77.0, the only non-test commit that mentions mutexes is f0119103956a425ff1e9f7759b80fcaaff944857 , "gsignal: Do not try to access to node members when unlocked"...
From the Python traceback this happens when anaconda runs hwclock --hctosys via subprocess.communicate(). Not sure if that's the first time subprocess is used in any given run of anaconda, maybe it is.
That's not the first command anaconda runs via subprocess during any given install cycle, but every failed test did fail on that specific command. So there seems to be something about it that causes the problem.
I can't reproduce the problem in a Rawhide VM with the newer glib2 just by doing subprocess.Popen(["hwclock", "--hctosys", "--utc"]).communicate() in a Python shell, though. Not even after setting the system clock forward first. So, there must be something more to it than that.
of course, just using python and subprocess, glib isn't going to be involved anywhere. duh. it's anaconda that involves glib. that makes getting a clean reproducer harder.
static void
_ctx_integ_source_reacquire(CtxIntegSource *ctx_src)
{
if (G_LIKELY(ctx_src->acquired && g_main_context_is_owner(ctx_src->context)))
return;
/* the parent context now iterates on a different thread.
* We need to release and reacquire the inner context. */
if (ctx_src->acquired)
g_main_context_release(ctx_src->context);
For help debugging failed Fedora CI tests (fedora-ci.*), contact the Fedora CI team.
For help debugging failed Fedora CoreOS tests (coreos.*), contact the Fedora CoreOS team.
For help debugging failed openQA tests (update.*), contact the Fedora Quality team, who will usually investigate and diagnose all failures within 24 hours.
This update was automatically created
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
This seems to consistently make anaconda crash on startup - same failure on Workstation live, KDE live, Everything netinst, and Silverblue installer image.
Short trace from the journal:
I'll try and get a full trace, but it can be a bit tricky for installer crashes...
More that I found after poking down
g_mutex_unlock_slowpatha bit:Looking at the diff from 2.76.4 to 2.77.0, the only non-test commit that mentions mutexes is f0119103956a425ff1e9f7759b80fcaaff944857 , "gsignal: Do not try to access to node members when unlocked"...
From the Python traceback this happens when anaconda runs
hwclock --hctosysviasubprocess.communicate(). Not sure if that's the first time subprocess is used in any given run of anaconda, maybe it is.That's not the first command anaconda runs via
subprocessduring any given install cycle, but every failed test did fail on that specific command. So there seems to be something about it that causes the problem.I can't reproduce the problem in a Rawhide VM with the newer glib2 just by doing
subprocess.Popen(["hwclock", "--hctosys", "--utc"]).communicate()in a Python shell, though. Not even after setting the system clock forward first. So, there must be something more to it than that.of course, just using python and subprocess, glib isn't going to be involved anywhere. duh. it's anaconda that involves glib. that makes getting a clean reproducer harder.
Full backtrace:
I guess it's pretty plausibly relevant that the command does change the system time (it changes it backwards by four hours, as best as I can tell).
The bit of libnm we wind up at seems to be this:
Line 4953 is that
g_main_context_releasecall.Filed https://gitlab.gnome.org/GNOME/glib/-/issues/3054 .
This update has been obsoleted by glib2-2.77.0-2.fc39.