mirror of
https://github.com/Tencent/flare.git
synced 2026-10-18 05:36:06 +08:00
CHEN Feng
6504d13b7b
* base: make heavy tests pass under sanitizers; fix latch_test data race Running `flare/base/...` under `--sanitizer=thread` surfaced one test-side data race and three tests too heavy to finish under instrumentation: - latch_test: `TEST(Latch, Torture)` runs `RunTest` on 10 threads, each ending with `std::cout << ...`; concurrent formatted output races the stream buffer. Serialize that line with a mutex. - spinlock_test: 100 threads x 100k contended lock cycles -- under a sanitizer each contended acquire spins an unbounded, instrumented number of times, so the run takes many minutes (well past the test timeout). The brute-force volume is the race detector in a non-sanitized build, so keep it there and scale down (8 threads x 2k) only under ASan/TSan, following the existing `scheduling_group_test` pattern (FLARE_INTERNAL_USE_ASAN/TSAN). - compression_test / view_test: their 10 MiB workloads (LargeSize, VariantSize's ~9.5k-size sweep, the noncontiguous-buffer searches) are slow to instrument and time out under parallel sanitizer runs. These are large-data, not brute-force-race, tests, so just shrink them unconditionally to sizes that still exercise the multi-block / cross-block paths (512 KiB, ~1 MiB, a coarser size sweep). The 2 GiB extreme stays covered by DISABLED_HugeSize. Verified: `flare/base/... --sanitizer=thread` is all green; the normal build is unaffected (full-size workloads still run there, except the unconditionally shrunk compression/view). * base/thread: add annotation dep to spinlock_test in BUILD.bazel spinlock_test.cc now includes flare/base/internal/annotation.h (for the ASan/TSan workload guard); the blade BUILD got the dep but the Bazel build needs it too.