[PATCH] Workaround hawkey test failures with CK_FORK=no.
authorMihai Moldovan <ionic@ionic.de>
Tue, 29 Sep 2020 16:30:16 +0000 (18:30 +0200)
committerLuca Boccassi <bluca@debian.org>
Mon, 6 May 2024 19:29:03 +0000 (20:29 +0100)
For a description of what is happening here and a rational of why this might
just be okay for us, see the source code comment.

Gbp-Pq: Name 0008-Workaround-hawkey-test-failures-with-CK_FORK-no.patch

tests/hawkey/test_goal.cpp

index 8ffde630497458a9f8e8de929db69e15e714bd33..30f2140c607828fe550f2b59cde1052a3a994c3d 100644 (file)
@@ -951,6 +951,27 @@ START_TEST(test_goal_upgrade_disabled_repo)
     auto pool = dnf_sack_get_pool(test_globals.sack);
     HyGoal goal = hy_goal_create(sack);
 
+    /*
+     * This is probably the weirdest workaround ever, but this test case fails
+     * with CK_FORK=no (which is used in the valgrind tests) for an unknown
+     * reason I wasn't able to figure out.
+     * However, just querying the sack, which should be a read-only operation,
+     * seems to remedy this problem.
+     * Since the failure doesn't happen with CK_FORK=yes, whatever is causing
+     * it is likely not a problem in libdnf/hawkey or the libsolv integration,
+     * but rather some sort of... stack or heap corruption? Or a side-effect
+     * of libcheck?
+     * Given that rationale, it's probably okay to mask the problem with this
+     * very weird workaround.
+     */
+    HyQuery q = hy_query_create (sack);
+    hy_query_filter (q, HY_PKG_REPONAME, HY_EQ, HY_SYSTEM_REPO_NAME);
+    GPtrArray *res = hy_query_run (q);
+    g_ptr_array_unref (res);
+    res = NULL;
+    hy_query_free (q);
+    q = NULL;
+
     hy_goal_upgrade_all(goal);
     hy_goal_run_flags(goal, DNF_NONE);
     int implicitobsoleteusescolors = pool_get_flag(pool, POOL_FLAG_IMPLICITOBSOLETEUSESCOLORS);