You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix data race in CPU-feature global, not just the dispatch pointers
The previous fix (PR #4) made the per-codec dispatch function pointers
(crc32_impl, adler32_impl, ...) atomic, but each dispatcher still calls
get_x86_cpu_features() / get_arm_cpu_features(), which lazily initialize the
global libdeflate_x86_cpu_features / libdeflate_arm_cpu_features bitmask on
the first call. That global was only 'volatile', so a plain load racing with
the store in libdeflate_init_*_cpu_features() is undefined behavior and was
still flagged by ThreadSanitizer:
WARNING: ThreadSanitizer: data race
Write ... libdeflate_init_x86_cpu_features cpu_features.c
Read ... get_x86_cpu_features cpu_features.h
Location is global 'libdeflate_x86_cpu_features'
This reproduced as a "Server died" failure when two HTTP connections first
compressed a gzip response concurrently under TSan.
Access the global with relaxed __atomic_load_n / __atomic_store_n, matching
the dispatch-pointer fix. The first-call initialization is a benign race
(every thread computes the same bitmask, a pure function of the CPU), and
relaxed ordering suffices because no other memory is published through it.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
0 commit comments