Failure Detector Expansion 4/5: Merge valgrind and sanitizer reports of one memory bug into one issue

[BChan-0]

Stacked on #79 (1/5). This branch contains 1/5's commit as its base, so the file list and diff include it. It's best to review and merge in numerical order, but this PR should be ok to merge after 1/5 and doesnt need to wait on 3/5; the diff size will lower as they merge

The producer side is valkey PR 4292.

Issue

Valgrind and the sanitizers surface the same bug under different methods.

PR Summary

A valgrind or sanitizer report is reduced to a (class, stack anchor) identity. The class is coarse on purpose; leak, use-after-free, buffer-overflow, uninitialized, invalid-free, wild-pointer, runtime-error; since it only has to
agree between two tools on one bug and disagree between two bugs at one site. Reports carrying that kind of identity share one marker namespace so they dedup against each other; anything unclassifiable keeps its per-tool namespace.

Valgrind's "Invalid read/write" is deliberately not mapped directly: it is shared by a use-after-free and an overflow, and only the address description that follows tells them apart. The unallocated form is tested first, because it contains the
word free'd while meaning the address was never a heap block, so matching on that word alone filed a null dereference as a use-after-free.

The anchor keeps two frames. That width is a tradeoff, not a tuned setting: the tools stop at different depths on one stack, so a wider chain can disagree between them and leave one bug with an issue per tool, while one frame is narrower than a bug and collapses two allocations reached through a shared constructor. Two prefers
the recoverable failure; a duplicate a maintainer can close over a report that is never filed.

A report whose diagnostics disagree on the class is refused rather than guessed at: a tool hands over its whole stderr buffer, so one report can describe several errors, and there is then no single bug for one identity to name. Agreeing
diagnostics are not refused, since a leak report names its leak once per loss record and again in the summary.

When two failures do merge, the absorbed tool's trace is carried onto the survivor and published in a comment rather than discarded, because each tool names details the other omits. The body still holds exactly one trace, so it keeps the shape of an issue filed by hand from the repository's template. Which failure survives is decided by sorting on type, so the issue's title does not alternate between the two tools' wording from run to run.

Testing

Added:

• tests/test_testfailuredetector_failure_parser.py: TestSourceLocationInStackAnchor, TestSanitizerLeakIdentityAcrossToolchains, TestMacosLeaksIdentity
• tests/test_testfailuredetector_issue_manager.py: TestCrossToolErrorClass, TestCrossToolMerge, TestCrossToolSeparation, TestCrossToolAnchorDepth, TestMergeSameFingerprintFailures, TestMergedIssueRecordsBothTools, TestAbsorbedTraceOnCreation, TestAbsorbedTraceReachesTheIssue, TestMultiTraceBody, TestRecurrenceCommentWithMultipleTraces, TestMergedBodyFitsGitHubLimit, TestValgrindBannerTitle, TestValgrindRecurrenceStaysQuiet, TestMacosLeaksTitle, TestLeakTitlesCarryNoMagnitude, TestDistinctLeaksGetDistinctTitles, TestForgedMarkersInTraceText, TestForgedRowHeadingsInTraceText, TestLongBacktickRunsCannotCloseTheFence, TestBodyMatchesTheHandFiledFormat, TestBodyShapeMatchesLegacyAcrossTypes, TestCommentsUseOnlyTemplateWording, TestCreationCommentCarriesItsContext, TestBothCommentsShareOneStructure, TestPublisherReuse

1591 total tests passed.

[coderabbitai]

Warning

Review limit reached

@BChan-0, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 59 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: faaca686-adc3-4f52-baba-612127828c35

📥 Commits

Reviewing files that changed from the base of the PR and between cab64ac and a482716.

📒 Files selected for processing (9)

• scripts/common/issue_dedup.py
• scripts/common/workflow_artifacts.py
• scripts/test_failure_detector/issue_renderer.py
• scripts/test_failure_detector/manage_issues.py
• scripts/test_failure_detector/parse_failures.py
• tests/test_issue_dedup.py
• tests/test_testfailuredetector_failure_parser.py
• tests/test_testfailuredetector_issue_manager.py
• tests/test_workflow_artifacts.py

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}