Skip to content

Fix TSAN data races

This is an epic to follow up on some of the thread sanitizer problems listed and partially fixed in #1224 (closed). Still remaining:

  • Unsynchronized read of GOnce status field from g_once (when G_ATOMIC_OP_MEMORY_BARRIER_NEEDED is undefined).
  • Unsynchronized read of GCancellable cancelled field from g_cancellable_is_cancelled.
  • Unsynchronized read of g_once_init_list in g_once_init_leave from assertion. Fixed in c2b22bd6.
  • Unsynchronized read of ref_count in g_variant_unref / g_variant_ref / g_variant_ref_sink from assertion. Fixed in 6d108587.
  • Unsynchronized read of ref_count in g_closure_ref / g_closure_unref from assertion.
  • Unsynchronized access to contention counters in slice allocator. (looks fishy: #1952 (closed))
    • Slice allocator has since been dropped entirely
  • Data race between g_task_return writing task->ever_returned = TRUE and g_task_run_in_thread reading task->thread_complete (same bitfield).
  • Unsynchronized read of ref_count in GDBus*Info structs. Fixed in b599a0f4 and b5a41afb.
  • GClosure mixes atomic compare and exchange with non atomic reads.
  • Unsynchronized access to GSource context field, #1178
    • wake_source from gmain.c reads source->context while holding main_context_list
    • g_source_attach / g_main_context_unref writes source->context while holding context->mutex
  • Unsynchronized read of GMainLoop is_running from g_main_loop_is_running.
  • Unsynchronized read of GSubprocess pid from g_subprocess_wait.
  • Unsynchronized read of unix_signal_pending, #1670 (closed)
  • Unsynchronized write of printed_scheduler_warning
  • Add a CI test to ensure we don’t regress (run the entire test suite under TSAN?) — see #3356
  • Lots of data races in owners read/write in 1bit-mutex test (see also #3539)

If any of these need more detailed investigation, please open a more specific task for it and link it here. The simple ones can just get an MR directly.

Edited by Marco Trevisan