New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
flatpak search assertion failure since port to libappstream: g_atomic_pointer_get (value_location) == 0
#384
Comments
smcv
added a commit
to smcv/appstream
that referenced
this issue
Feb 26, 2022
The token cache only needs to be created once per AsComponent. Previously, each of the two callers of as_component_create_token_cache() guarded it with an atomic (GOnce) access to priv->token_cache_valid, but the implementation had a redundant non-atomic guard. This resulted in a GLib assertion failure on leaving the function, because the atomic boolean flag indicating whether initialization has completed is not meant to be set non-null until g_once_init_leave(). In particular, this resolves test failures in Flatpak 1.13.x (which has been ported from libappstream-glib to libappstream) when it runs `flatpak search` from its test suite. Resolves: ximion#384 Signed-off-by: Simon McVittie <smcv@debian.org>
ximion
pushed a commit
that referenced
this issue
Mar 5, 2022
The token cache only needs to be created once per AsComponent. Previously, each of the two callers of as_component_create_token_cache() guarded it with an atomic (GOnce) access to priv->token_cache_valid, but the implementation had a redundant non-atomic guard. This resulted in a GLib assertion failure on leaving the function, because the atomic boolean flag indicating whether initialization has completed is not meant to be set non-null until g_once_init_leave(). In particular, this resolves test failures in Flatpak 1.13.x (which has been ported from libappstream-glib to libappstream) when it runs `flatpak search` from its test suite. Resolves: #384 Signed-off-by: Simon McVittie <smcv@debian.org>
4 tasks
alexlarsson
added a commit
to alexlarsson/flatpak
that referenced
this issue
Jun 16, 2022
We need appstream >= 0.15.3 to get this fix: ximion/appstream#384 Without it the test-suite fails.
alexlarsson
added a commit
to alexlarsson/flatpak
that referenced
this issue
Jun 16, 2022
We need appstream >= 0.15.3 to get this fix: ximion/appstream#384 Without it the test-suite fails.
alexlarsson
added a commit
to alexlarsson/flatpak
that referenced
this issue
Jun 16, 2022
We need appstream >= 0.15.3 to get this fix: ximion/appstream#384 Without it the test-suite fails.
alexlarsson
added a commit
to alexlarsson/flatpak
that referenced
this issue
Jun 16, 2022
We need appstream >= 0.15.3 to get this fix: ximion/appstream#384 Without it the test-suite fails.
alexlarsson
added a commit
to alexlarsson/flatpak
that referenced
this issue
Jun 16, 2022
We need appstream >= 0.15.3 to get this fix: ximion/appstream#384 Without it the test-suite fails.
alexlarsson
added a commit
to alexlarsson/flatpak
that referenced
this issue
Jun 16, 2022
We need appstream >= 0.15.3 to get this fix: ximion/appstream#384 Without it the test-suite fails.
alexlarsson
added a commit
to alexlarsson/flatpak
that referenced
this issue
Jun 16, 2022
We need appstream >= 0.15.3 to get this fix: ximion/appstream#384 Without it the test-suite fails.
alexlarsson
added a commit
to flatpak/flatpak
that referenced
this issue
Jun 16, 2022
We need appstream >= 0.15.3 to get this fix: ximion/appstream#384 Without it the test-suite fails.
debarshiray
added a commit
to debarshiray/flatpak
that referenced
this issue
Jun 17, 2022
... to have the fix for: ximion/appstream#384 Otherwise, the 'flatpak search' output gets littered with CRITICALs, which also breaks the test suite. Given that appstream doesn't seem to have any stable branches [1], and this is part of a new unstable Flatpak series that's meant for new (even future?) distributions, there's probably no need to be too conservative with the minimum required appstream version. [1] https://github.com/ximion/appstream
debarshiray
added a commit
to debarshiray/flatpak
that referenced
this issue
Jun 17, 2022
... to have the fix for: ximion/appstream#384 Otherwise, the 'flatpak search' output gets littered with CRITICALs, which also breaks the test suite. However, appstream releases newer than 0.12.5 are impossibly difficult to build on RHEL 8 [1]. This can make it difficult to put a future Flatpak 1.14.x into RHEL 8, if necessary. [1] flatpak#4426
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Relevant package versions:
with flatpak git HEAD, on Debian unstable. (Note that flatpak 1.12.x used libappstream-glib, but git HEAD has switched to libappstream.)
Steps to reproduce: run the Flatpak test suite
Expected result: tests succeed
Actual result: several tests fail with this assertion failure in libappstream:
Backtrace:
This seems to be a bug in libappstream rather than a bug in Flatpak. The assertion failure is here:
because both
as_component_create_token_cache()and theg_once_init_enter()/g_once_init_leave()pair are trying to be responsible for writing topriv->token_cache_valid:The text was updated successfully, but these errors were encountered: