Add an opt-in for capturing sanitizer logs from the language server#14573
Open
sean-mcmanus wants to merge 3 commits into
Open
Add an opt-in for capturing sanitizer logs from the language server#14573sean-mcmanus wants to merge 3 commits into
sean-mcmanus wants to merge 3 commits into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix by Copilot with Claude Opus 4.8 in VS Code.
Problem
When running a sanitizer build of the language server (a
-tsan/-asan/-ubsanCMake preset), the sanitizer prints its reports to stderr. Because the
extension talks to the language server over stdio, those reports are easily
lost, and a crash log only shows the sanitizer shutting down, not the actual
report. There was no convenient, checked-in way to capture them, so developers
resorted to attaching a debugger (which can hang the process at shutdown) or
hand-editing the spawn code.
Change
Add an opt-in, gated on the CPPTOOLS_SANITIZER_LOG_DIR environment variable:
is set, it routes each sanitizer's log_path into that directory and returns the
merged env for the spawned language server; the cpptools-srv/-srv2 children
inherit it, so every process writes its own "/." file
(tsan/asan/ubsan). Any TSAN_OPTIONS/ASAN_OPTIONS/UBSAN_OPTIONS the developer
already set are preserved. The helper best-effort creates the directory
(the sanitizer runtime does not create a missing one; without it reports
silently fall back to stderr). It is wired into both the run and debug
ServerOptions.
helper returns undefined, leaving the child environment inherited unchanged --
a true no-op, safe to leave checked in.
configuration (based on "Run Extension") that sets
CPPTOOLS_SANITIZER_LOG_DIR=${userHome}/cpptools-sanitizer-logs, so a developer
can just pick it from the Run and Debug dropdown.
server" section (with a Table of Contents entry) documenting the variable, the
launch configuration, and how to read the resulting files.
Usage
Build a sanitizer preset of the language server, pick "Run Extension (capture
sanitizer logs)" from the Run and Debug dropdown (or set
CPPTOOLS_SANITIZER_LOG_DIR yourself), reproduce, then read
~/cpptools-sanitizer-logs/tsan. (or asan.* / ubsan.*). No debugger is
required, which also avoids the shutdown-time hang that can occur when a
debugger is attached to a sanitizer process as it exits.
Notes
handler changes are a separate PR in the VS repo.
Testing
Ran a TSan build of the language server with the new launch configuration;
reports were written to ~/cpptools-sanitizer-logs/tsan.. With the variable
unset, the spawned environment is unchanged and there is no behavior difference.