Add ASan/TSan sanitizer support and CI jobs#98
Add ASan/TSan sanitizer support and CI jobs#98siddimore wants to merge 3 commits intolivekit:mainfrom
Conversation
siddimore
commented
Apr 15, 2026
siddimore
commented
- Add LIVEKIT_SANITIZER CMake option (address, thread, undefined)
- 'address' enables ASan + UBSan with -fno-omit-frame-pointer
- 'thread' enables TSan
- 'undefined' enables UBSan standalone
- Blocked on Windows (MSVC lacks TSan/UBSan); works on Linux and macOS
- Add linux-debug-asan and linux-debug-tsan CMake presets with corresponding build and test presets
- Add 'sanitizers' CI job in builds.yml with ASan and TSan matrix
- Fix reversed markdown link syntax in README.md
- Add LIVEKIT_SANITIZER CMake option (address, thread, undefined) - 'address' enables ASan + UBSan with -fno-omit-frame-pointer - 'thread' enables TSan - 'undefined' enables UBSan standalone - Blocked on Windows (MSVC lacks TSan/UBSan); works on Linux and macOS - Add linux-debug-asan and linux-debug-tsan CMake presets with corresponding build and test presets - Add 'sanitizers' CI job in builds.yml with ASan and TSan matrix - Fix reversed markdown link syntax in README.md
siddimore
changed the title
The TSan CI job referenced tsan_suppressions.txt with a relative path, which resolved against the test binary directory instead of the repo root. - Create tsan_suppressions.txt with Rust FFI suppressions - Use $GITHUB_WORKSPACE absolute path in TSAN_OPTIONS
| - name: Build | ||
| run: cmake --build --preset ${{ matrix.preset }} | ||
|
|
||
| - name: Run unit tests |
There was a problem hiding this comment.
Hi there @siddimore: can you explain the decision to make this a separate stage (Sanitizer - <arch>) vs. incorporating the sanitizer steps into the existing build steps?
There's a lot of duplication in setup here, and definitely a tradeoff between parallelizing the workflow vs. too much duplication.
There was a problem hiding this comment.
That is a fair point since this was my first PR in this repo wanted to tread carefully plus these other reasons:
- ASan/TSan require recompilation with different flags (-fsanitize=address vs -fsanitize=thread), so you can't just re-run existing binaries
- Existing matrix includes macOS and Windows, which don't need sanitizer runs
- Isolation — a TSan failure shouldn't block the macOS or Windows build result
but i m happy to avoid the duplication which u identified in the setup which is the right call. I will update the PR later today. Thanks for your review
There was a problem hiding this comment.
Hello again, I actually thought more about your PR after my original comment, and for sure the different compiler flags make a difference. For context, I am working on a "quality build" stage that ideally could handle the following:
- clang-tidy (open PR)
- sanitizer builds
- code coverage (debug flag builds)
It will probably take a little bit more time for me to fully flesh out that idea and see what stages we could combine configuration/compiler-flag wise. So feel free to iterate on your PR here, but we will probably want to bundle that in later with the other quality items. Stay tuned, thanks!
Fold the separate 'sanitizers' job into the existing 'build' matrix as two additional Linux entries (linux-x64-asan, linux-x64-tsan). This eliminates ~100 lines of duplicated setup (checkout, apt-get, Rust, Cargo cache) while preserving identical parallel execution behavior. Sanitizer matrix entries use a 'sanitizer: true' flag to conditionally: - Use cmake --preset instead of build.sh - Skip example smoke tests and build artifact uploads - Pass sanitizer-specific env vars (TSAN_OPTIONS) to the test runner
2 participants
