tmux Clang Static Analyzer Triage

A self-contained workspace for parsing, aggregating, and triaging Clang Static Analyzer (clangsa) findings on the tmux source tree. Raw CodeChecker plist reports are turned into deduplicated findings, each of which receives a rule-based verdict — true positive, false positive, or needs confirmation — with root cause, path evidence, rationale, and a fix or verification recommendation.

• Analyzed source: tmux commit 851c5a933d4838c32ad06c248b2ba975d106149c (checked out under tmux/)
• Reports: 158 CodeChecker 6.26.2 plists (47 empty, 111 with diagnostics) under reports/
• Volume: 819 raw diagnostics aggregated into 458 unique findings

Results at a glance

Verdict	Unique findings	Raw occurrences
True positive	12	15
False positive	363	693
Needs confirmation	83	111
Total	458	819

The highest-value confirmed issues:

• Uninitialized mouse-drag coordinates (server-client.c:1192) — a drag event on the status line can skip the branch that computes pane coordinates, then store the uninitialized values into mouse_drag_x/y.
• Stale window-tree items (sort.c:249, window-tree.c:1033) — window_tree_pull_item may return NULL, but the result is passed to sort_winlink_cmp unchecked, and when both sessions are NULL an equality check passes and other_winlink is dereferenced directly.
• qsort(NULL, 0, ...) contract violations (sort.c:49, window-switch.c:230) — an empty list leaves the base pointer NULL while qsort is declared nonnull.
• 7 dead stores — real but low-risk code-quality warnings.

Most memory-related reports are not actual leaks: the analyzer does not model ownership transfer via return values/output parameters, tmux reference counting, teardown of asynchronous state objects, or node identity inside expanded TAILQ/RB macros. Findings whose async completion, cancellation, or disconnect paths cannot be proven from the plists alone are kept as needs confirmation rather than forced into a binary verdict.

Repository layout

tmuxana/
├── triage_clangsa.py          # Parser, aggregator, classifier, and exporters
├── clangsa-findings.csv       # Full findings export (one row per unique finding)
├── clangsa-triage.md          # Generated triage report (in Chinese)
├── checker-reference-files.txt    # Hand-picked plists used as checker references
├── checker-reference-hashes.txt   # Corresponding report hashes
├── reports/                   # CodeChecker 6.26.2 plist reports + analysis metadata
└── tmux/                      # tmux source snapshot at the analyzed commit

Usage

Requires Python 3.8+ with only the standard library. Run from the workspace root:

# Print report/finding counts and per-checker statistics as JSON
python triage_clangsa.py --summary

# Interactively list findings, filtered by regex over file/description/code/functions
python triage_clangsa.py --inspect "mouse_drag"

# Restrict output to a single checker (combine with --inspect)
python triage_clangsa.py --checker unix.Malloc

# Write all findings as normalized JSON
python triage_clangsa.py --json findings.json

# Regenerate clangsa-findings.csv and clangsa-triage.md (runs built-in validation)
python triage_clangsa.py --export

--export asserts the expected invariants (158 reports, 819 raw diagnostics, 458 unique findings, 117 referenced files with none missing, and a complete verdict on every row) before writing the CSV and Markdown outputs.

How it works

1. Path mapping — plist reports reference the original analysis root (/home/zfx/workplace/clangTestCode/autocheckerv2/datasets/real/tmux), which is remapped to the local tmux/ tree. All 117 referenced files exist locally; no fuzzy filename matching is used.
2. Aggregation — diagnostics are grouped by checker, issue_hash_content_of_line_in_context, old source path, line, column, and description. Duplicates within the same translation unit accumulate into occurrence_count; findings with different leaked fields or operands stay separate.
3. Classification — each finding is matched against curated verdict rules (specific finding IDs and per-checker root-cause patterns) that produce a verdict, a confidence level, a root cause, a rationale, and a recommendation.
4. Inspection — every verdict was reached by reading the full path events, the reported source line, allocation/free events, and the relevant call contracts. The CSV path_evidence column compresses only the middle of very long paths; start and end events are always preserved.

Note: the generated clangsa-triage.md and the CSV verdict columns are written in Chinese. The labels map as follows: 真告警 = true positive, 假警报 = false positive, 待确认 = needs confirmation; 高/中/低 = high/medium/low confidence.

CSV columns

Column	Content
finding_id	Stable ID (F0001…F0458) assigned after sorting by file/line/column/checker
classification / confidence	Verdict and confidence level
root_cause	Root-cause family for the verdict
checker / category	clangsa checker name and diagnostic category
source_file / line / column / source_code	Reported location and the source line at that location
description	Analyzer diagnostic text
occurrence_count / report_files	How many plists reported it, and which ones
old_source_path	Original path recorded in the plist
path_evidence	Compact event trace of the representative path
rationale / recommendation	Why the verdict was reached, and the suggested fix or verification step

Limitations

• The Clang Static Analyzer, ASan/LSan, and the tmux regression suite were not re-run as part of this triage. Verdicts rely on the current source snapshot and the plists only.
• Findings involving asynchronous callbacks and external library contracts cannot be fully proven from static paths, so they are listed as needs confirmation with a minimal dynamic-verification step (typically ASan/LSan runs covering completion, cancellation, and client-disconnect paths).
• Conclusions apply only to the source snapshot named above.

References

• Clang Static Analyzer available checkers — semantics of unix.Malloc and optin.portability.UnixAPI
• CodeChecker — the report format (plist) consumed here
• tmux — the analyzed project