Skip to content

Log fuzz crash inputs as base64 for reproducibility - #429

Draft
Saurabh Singh (saurabh500) wants to merge 1 commit into
mainfrom
dev/saurabh/fix-fuzz-crash-9ff
Draft

Log fuzz crash inputs as base64 for reproducibility#429
Saurabh Singh (saurabh500) wants to merge 1 commit into
mainfrom
dev/saurabh/fix-fuzz-crash-9ff

Conversation

@saurabh500

@saurabh500 Saurabh Singh (saurabh500) commented Aug 30, 2026

Copy link
Copy Markdown
Contributor

Summary

When the GH-Rust Fuzz Test pipeline detects a crash, the build log records only the crash file name (a SHA1). The crashing input bytes live only inside the published pipeline artifact, which is not reliably retrievable — artifact downloads can be auth-restricted and pipeline retention expires. Once the artifact is gone or inaccessible, the SHA1 filename alone cannot recreate the input, so the crash cannot be reproduced or turned into a regression test.

This change makes the crash-handling step in .pipeline/templates/fuzz-template.yml echo each crash input as base64 into the build log (bounded to 4096 bytes), so every future fuzz crash is reproducible from the log alone, independent of artifact access or retention.

Background

This was found while investigating the last fuzz-crash failure in the pipeline: build 164079 (2026-08-01), target fuzz_token_stream, crash crash-80c55599ebe9adee81668324e4c6151894a33fbe ("libFuzzer: deadly signal").

  • There are no fuzz-crash failures in the last 24h — the pipeline is green on its 3-hour schedule.
  • The Aug-1 panic is already fixed on current main: reproducing against current HEAD (harness reusing the exact fuzz path with --cfg fuzzing, dev profile with overflow-checks + debug-assertions) found 0 panics across 15.3M random trials (all 256 first-bytes × 60k, lengths 1–48) and a full replay of the committed seed corpus (137/137 inputs).
  • The original crash artifact could not be downloaded to attach to the work item (TF400813 via API, AADSTS50173 via az) — which is exactly the gap this PR closes.

Change

  • .pipeline/templates/fuzz-template.yml: in the crash-found branch of the "Run Fuzzer" step, emit base64 of each crash-* file into the log. YAML validated.

Testing

  • YAML parses cleanly (yaml.safe_load).
  • Shell logic guards input size (≤ 4096 bytes) and iterates crash files safely; the crash branch already fails the build, so the added logging cannot cause a passing build to fail.

Work item: AB#47707

Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com

When a fuzz crash is detected the build log recorded only the crash file name (a SHA1); the input bytes lived only in the published pipeline artifact, which can be auth-restricted to download and expires with retention. Echo each crash input as base64 (bounded to 4096 bytes) so crashes stay reproducible from the log alone.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
@github-actions

Copy link
Copy Markdown

📊 Code Coverage Report

🔥 Diff Coverage

100%

🎯 Overall Coverage

93.1%

📦 Project: mssql-tds + mssql-odbc + mssql-py-core
ℹ️ Note: diff coverage is reported, not enforced.


Diff Coverage

Diff: main...HEAD, staged and unstaged changes

No lines with coverage information in this diff.


🔗 Quick Links

View Azure DevOps Build · Coverage Report

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant