These tests create a server thread in setup() and join it in teardown(), but there are various race conditions between them that can cause the test to hang. These are particularly reproducible when building on a single-CPU machine or VM, and particularly in the startup_shutdown test (which doesn't do anything, so it runs teardown() immediately after setup()).
It's possible to get this preemption pattern:
___ Main thread ___ ___ Server thread ___
g_thread_new() (starts)
g_cond_wait() (blocks)
...
g_cond_signal()
(gets preempted here)
exit setup()
enter teardown()
g_main_loop_quit()
g_main_loop_run()which means g_main_loop_run() will never terminate, because it wasn't running yet when the main thread told the GMainLoop to quit, and the main thread won't tell it to quit again.
One way to solve this would be for the server thread to signal test->cond from an idle callback instead of directly from server_thread(), to guarantee that the GMainLoop is already running. However, it seems easier to reason about if we avoid GMainLoop and iterate the main context directly.