memcheck: fix race in libgit2...

...caused by incorrectly setting and resetting the library internal
state and the misuse of pthreads in libgit2.

Normally, git_libgit2_init and git_libgit2_shutdown should span the
life of a worker thread in order to be safely used. However, due to
an incorrect implementation of libgit2's threadstate with pthreads,
on unix systems there is a race condition.

Until the use of pthread_key_t is corrected in libgit2, we need to
apply a workaround by always ensuring that the main thread is the
first thread reaching the GitContext constructor.

1 files changed, 8 insertions, 0 deletions

diff --git a/test/utils/remote_execution/main-remote-execution.cpp b/test/utils/remote_execution/main-remote-execution.cpp
index 7dd48d92..49b0b617 100644
--- a/test/utils/remote_execution/main-remote-execution.cpp
+++ b/test/utils/remote_execution/main-remote-execution.cpp
@@ -86,6 +86,14 @@ auto main(int argc, char* argv[]) -> int {
         return EXIT_FAILURE;
     }
 
+    /**
+     * The current implementation of libgit2 uses pthread_key_t incorrectly
+     * on POSIX systems to handle thread-specific data, which requires us to
+     * explicitly make sure the main thread is the first one to call
+     * git_libgit2_init. Future versions of libgit2 will hopefully fix this.
+     */
+    GitContext::Create();
+
     int result = Catch::Session().run(argc, argv);
 
     // valgrind fails if we terminate before grpc's async shutdown threads exit