Sanitize Crash Stack

Transform a raw symbolicated native crash stack into a paste-ready comment for issues.chromium.org, crbug.com, or a Chromium Gerrit CL description. Public trackers require module names and debug output to be free of downstream product identifiers and environment PII; enforce a consistent sanitization and trimming pipeline so every posted stack has the same shape and safety guarantees.

When This Skill Applies

Trigger on a pasted crash stack combined with any of:

• Intent to file or comment on a public bug (crbug.com, issues.chromium.org, bugs.chromium.org)
• Intent to attach to a Gerrit CL description or review comment
• Explicit phrases like "sanitize", "scrub", "脱敏", "clean up before posting"

Skip this skill when:

• The target is a private/internal tracker and the user explicitly wants the raw stack preserved
• The stack is not symbolicated (raw addresses + pdb only) — ask the user to symbolicate first using windbg / minidump_stackwalk / llvm-symbolizer
• The stack is already in Chromium-standard form with no downstream identifiers — in that case offer trim-only mode (Steps 4-6) and skip scrub steps

Input Handling

Locate the stack trace via:

1. If invoked with a file path argument, read the file with the Read tool
2. Otherwise, scan the most recent user messages for a block of lines matching native stack trace patterns (function names with !, line numbers, source file references)
3. If no stack is found, ask the user to paste one

Do not proceed without an explicit stack. Do not fabricate or reconstruct missing frames.

Pipeline

Execute the six steps in order. Record each transformation to produce the final diff summary.

Step 1: Scrub Downstream Module Names

Regex-scan for module name patterns: ^\s*(\w+)\.(dll|exe|so|dylib)!.

Collect every unique module name observed. Classify each as:

• Chromium-standard: chrome, chrome_elf, content_shell, chromedriver, libchrome, or any module prefixed with test_
• Downstream / unknown: anything else (examples: brave, vivaldi, opera, msedge, custom embedder names)

Replacement rules:

• Chromium-standard → preserve as-is; record "Symbols from upstream Chromium build" for the provenance line
• Downstream → replace every occurrence with chrome.dll (or matching extension: .exe→chrome.exe, .so→libchrome.so, .dylib→libchrome.dylib); record "Module names normalized to chrome.* (symbolicated against upstream source)" for the provenance line

If multiple distinct downstream modules appear, treat as a warning and list all observed names under Safety Review for human confirmation — this may indicate a mixed-process or mis-symbolicated stack.

Step 2: Normalize Locale Tokens

Apply these substitutions before rendering:

Debugger locale pollution is common on Windows; MSVC and WinDbg emit localized line markers depending on the developer's OS language.

Step 3: Collapse C++ Template Signatures

Apply the substitution table, in order. Earlier rules must run before later ones because later rules assume earlier cleanup already happened.

Preserve these types verbatim: scoped_refptr<T>, base::WeakPtr<T>, base::OnceCallback<Sig>, base::RepeatingCallback<Sig>, raw_ptr<T>, raw_ref<T>.

Step 4: Classify Signal vs Noise Frames

Keep as signal:

• Any frame with a source path under chrome/, components/, content/, blink/, third_party/blink/, ui/, net/, gpu/, services/, sandbox/
• Any frame whose function name matches a class or method mentioned in the current bug context
• The *::AcceptSyncMessage frame from IPC::ChannelAssociatedGroupController — always keep; this is the decisive marker for sync IPC race diagnosis
• At least one mojo::InterfaceEndpointClient::HandleValidatedMessage frame for mojo dispatch context
• Generated mojo *::StubDispatch::AcceptWithResponder frames

Elide as noise, replacing the contiguous tail at the bottom of the stack with a single summary line.

For the authoritative list of noise-frame families and patterns, consult:

• references/noise-frames.md — Complete Chromium boilerplate frame classification with regex patterns

The most commonly elided families:

• base::internal::* (Bind/Invoke machinery)
• base::TaskAnnotator::*
• base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::*
• base::MessagePump*::*, base::RunLoop::*
• content::BrowserMainLoop::*, content::BrowserMain*, content::ContentMain*
• ChromeMain, MainDllLoader::*, wWinMain, main, WinMain
• Mojo dispatch middle frames: MessageDispatcher::Accept, HandleIncomingMessage, HandleIncomingMessageThunk::Accept
• Sibling mojo stub wrappers: *::Stub<RawPtrImplRefTraits>::AcceptWithResponder (keep only StubDispatch variant)

Replace the elided tail with one line matching the actual boilerplate family:

[base::Bind / TaskAnnotator / MessagePumpForUI / BrowserMain — standard UI-thread dispatch, elided]

Adjust the summary if the crash is on a worker thread (mention ThreadPoolImpl::Worker instead), or on an IO thread (MessagePumpLibevent or similar).

Step 5: Render Markdown Output

Format the sanitized stack as:

1. Provenance paragraph (outside the code block). Adjust to reflect only the transformations that were actually performed:

   Adding the browser-side crash stack for context. Symbolicated against upstream source; module names normalized to chrome.*, C++ template signatures shortened, standard UI-thread dispatch tail elided. Line numbers are from a symbolicated downstream build and may differ by a few from upstream HEAD.

2. Fenced code block containing the sanitized frames. Each frame occupies two lines:

   • Line 1: module.dll!<function signature> (collapsed per Step 3)
   • Line 2, indented 4 spaces: source_file.cc:line_number

3. Elision marker as the last line inside the code block.

4. Optional ### Why this stack matters section if any of these conditions hold:

   • An AcceptSyncMessage frame is present — explain the sync IPC race window in one paragraph
   • The crash is inside a bound callback invoked from TaskAnnotator — note that the failing work was posted from elsewhere, so the poster site is not directly visible
   • The stack spans a known Chromium trap (re-entrancy into a destroyed object, UAF during shutdown, etc.)

Step 6: Safety Review

Scan the sanitized stack for residual risk patterns before presenting it:

Do not auto-delete flagged items — list them under a ### Safety review section for human judgment. A CamelCase class name that looks l