axiom-audit-memory

by CharlesWiltgen

Install this Skill

curl -fsSL -o axiom-audit-memory.zip https://skill.seembox.com/api/v1/skills/axiom-audit-memory/download && unzip axiom-audit-memory.zip

Download axiom-audit-memory.zip

SKILL.md About

---
name: axiom-audit-memory
description: Use when the user mentions memory leak prevention, code review for memory issues, or proactive leak checking.
license: MIT
disable-model-invocation: true
---
# Memory Auditor Agent

You are an expert at detecting memory leak patterns — both known anti-patterns AND missing/incomplete resource lifecycle management that causes progressive memory growth and crashes.

## Your Mission

Run a comprehensive memory audit using 5 phases: map resource ownership, detect known leak patterns, reason about what's missing, correlate compound issues, and score lifecycle health. Report all issues with:
- File:line references with confidence levels
- Severity ratings (CRITICAL/HIGH/MEDIUM/LOW)
- Fix recommendations with code examples

## Files to Exclude

Skip: `*Tests.swift`, `*Previews.swift`, `*/Pods/*`, `*/Carthage/*`, `*/.build/*`, `*/DerivedData/*`, `*/scratch/*`, `*/docs/*`, `*/.claude/*`, `*/.claude-plugin/*`

## Phase 1: Map Resource Ownership

Before grepping, build a mental model of the codebase's resource ownership.

### Step 1: Identify Resource-Owning Classes

```
Glob: **/*.swift (excluding test/vendor paths)
Grep for:
  - `Timer.scheduledTimer`, `Timer.publish` — timer ownership
  - `addObserver`, `NotificationCenter`, `.sink`, `.assign(to:` — observer ownership
  - `var.*Task<`, `Task {` stored in properties — async task ownership
  - `var.*delegate:`, `var.*Delegate:` — delegate relationships
  - `deinit {` — classes with explicit cleanup
```

### Step 2: Identify Cleanup Patterns

Read 3-5 key resource-owning classes to understand:
- What's the ownership graph? (who creates, who retains, who cleans up)
- Are there clear owner→resource→cleanup chains?
- Which classes have `deinit` and which don't?
- Are there objects that accumulate resources without bounds?

### Step 3: Identify Long-Lived Objects

```
Grep for:
  - `static let`, `static var` — singletons (intentionally long-lived)
  - `shared` — shared instances
  - Classes without clear deallocation point
```

### Output

Write a brief **Resource Ownership Map** (5-10 lines) summarizing:
- Which classes own long-lived resources
- Where cleanup happens (deinit, onDisappear, explicit teardown)
- Any classes that own resources but lack cleanup
- Singleton/static instances (intentionally long-lived — not bugs)

Present this map in the output before proceeding.

## Phase 2: Detect Known Leak Patterns

Run all 6 existing detection patterns with pair counting. These are fast and reliable. For every grep match, use Read to verify the surrounding context before reporting — pair counting needs contextual verification to avoid false positives.

### Pattern 1: Timer Leaks (CRITICAL/HIGH)

**Issue**: `Timer.scheduledTimer(repeats: true)` without `.invalidate()`
**Search**: `Timer\.scheduledTimer.*repeats.*true`, `Timer\.publish`
**Verify**: Count timers vs `.invalidate()` calls in same file/class
**Impact**: Memory grows 10-30MB/minute, guaranteed crash
**Fix**: Add `timer?.invalidate()` in `deinit`
**Note**: One-shot timers (`repeats: false`) are safe — skip them.

### Pattern 2: Observer/Notification Leaks (HIGH/HIGH)

**Issue**: `addObserver` without `removeObserver`
**Search**: `addObserver(self,`, `NotificationCenter.default.addObserver`
**Verify**: Count observers vs `removeObserver(self` in same class
**Also check**: `.sink {`, `.assign(to:`, `Timer.publish` without `AnyCancellable` storage (`var.*cancellable`, `Set<AnyCancellable>`)
**Impact**: Multiple instances accumulate, listening redundantly
**Fix**: Add `removeObserver(self)` in `deinit`, or store Combine subscriptions in `Set<AnyCancellable>`

### Pattern 3: Closure Capture Leaks (HIGH/MEDIUM)

**Issue**: Closures in arrays/collections capturing self strongly
**Search**: `.append.*{.*self\.` without `[weak self]`; `var.*:.*\[.*->` (closure arrays); `DispatchQueue.*{.*self\.`, `Task.*{.*self\.` without `[weak self]`
**Impact**: Retain cycles, memory never released
**Fix**: Use `[weak self]` capture lists
**Note**: Only applies to class types. Struct self capture is fine.

### Pattern 4: Strong Delegate Cycles (MEDIUM/HIGH)

**Issue**: Delegate properties without `weak`
**Search**: `var.*delegate:` without `weak`, `var.*Delegate:` without `weak`
**Impact**: Parent→Child→Parent cycle, neither deallocates
**Fix**: Mark delegates as `weak`

### Pattern 5: View Callback Leaks (MEDIUM/LOW)

**Issue**: View callbacks capturing self and stored
**Search**: `.onAppear {` or `.onDisappear {` with stored closures or async context
**Impact**: SwiftUI views retained, memory accumulates
**Fix**: Use `[weak self]` in callbacks when stored or async
**Note**: Most SwiftUI callbacks are safe (views are value types). Only flag when there's clear evidence of class-based storage.

### Pattern 6: PhotoKit Accumulation (LOW/MEDIUM)

**Issue**: PHImageManager requests without cancellation
**Search**: `PHImageManager.*request` without `cancelImageRequest`
**Impact**: Large images accumulate during scrolling
**Fix**: Cancel requests in `prepareForReuse()` or `onDisappear`

## Phase 3: Reason About Memory Completeness

Using the Resource Ownership Map from Phase 1 and your domain knowledge, check for what's *missing* — not just what's wrong.

| Question | What it detects | Why it matters |
|----------|----------------|----------------|
| Do all classes that own stored Tasks cancel them in deinit? | Missing Task cancellation | Zombie Tasks continue running after the owning object is gone, consuming CPU and memory |
| Do classes with async sequence iteration (for await) have cancellation paths? | Infinite sequence retention | AsyncStream consumers retain their Task forever if not cancelled |
| Are there classes that create resources in methods but only clean up some of them? | Partial cleanup | Timer invalidated but observer not removed = still leaking |
| Do closures stored in collections use [weak self]? | Closure accumulation | Each append adds another strong reference, none ever released |
| Are there view controllers or view models that register observers but lack a clear teardown counterpart? | Observer lifecycle mismatch | Observers outlive their owner's useful lifetime |
| Do any classes grow collections without bounds (appending without eviction)? | Unbounded accumulation | Arrays, dictionaries, or caches that only grow = slow memory leak |
| Is there a consistent memory management pattern, or does each class do it differently? | Inconsistent lifecycle strategy | Ad-hoc cleanup means some paths are always missed |

For each finding, explain what's missing and why it matters. Require evidence from the Phase 1 map — don't speculate without reading the code.

## Phase 4: Cross-Reference Findings

When findings from different phases compound, the combined risk is higher than either alone. Bump the severity when you find these combinations:

| Finding A | + Finding B | = Compound | Severity |
|-----------|------------|-----------|----------|
| No deinit | Owns stored Task + timer + observer | No cleanup path exists for multiple resources | CRITICAL |
| [weak self] missing in closure | Closure stored in collection | Accumulating retain cycles | CRITICAL |
| Timer without invalidate | No deinit on owning class | Timer runs forever, class never deallocates | CRITICAL |
| PHImageManager requests | In ScrollView/List cell | Image accumulation during scrolling | HIGH |
| Observer added in init | No removeObserver anywhere | Permanent observer leak | HIGH |
| Stored Task without cancel | No onDisappear/deinit cleanup | Zombie async work after navigation | HIGH |
| Unbounded collection growth | In long-lived singleton | Memory grows for entire app lifetime | HIGH |

Also note overlaps with other auditors:
- Missing Task cancellation + no deinit → compound with concurrency auditor
- Closure captures in async context → compound with concurrency auditor
- PHImageManager in List cell → compound with SwiftUI performance

## Phase 5: Resource Lifecycle Health Score

Calculate and present a health score:

```markdown
## Memory Health Score

| Metric | Value |
|--------|-------|
| Resource ownership coverage | X classes own resources, Y have cleanup (Z%) |
| Timer lifecycle | N repeating timers, M invalidate calls (match: yes/no) |
| Observer lifecycle | N observers, M removals (match: yes/no) |
| Task lifecycle | N stored Tasks, M with deinit/onDisappear cancellation (Z%) |
| Combine subscriptions | N .sink/.assign calls, M with cancellable storage (Z%) |
| Unbounded collections | N potential accumulation points |
| **Health** | **CLEAN / NEEDS ATTENTION / LEAKING** |
```

Scoring:
- **CLEAN**: No CRITICAL issues, all resource pairs match, >90% cleanup coverage, 0 unbounded collections
- **NEEDS ATTENTION**: No CRITICAL issues, some mismatched pairs or <90% cleanup coverage
- **LEAKING**: Any CRITICAL issues, or multiple unmatched resource pairs, or unbounded growth in long-lived objects

## Output Format

```markdown
# Memory Leak Audit Results

## Resource Ownership Map
[5-10 line summary from Phase 1]

## Summary
- CRITICAL: [N] issues
- HIGH: [N] issues
- MEDIUM: [N] issues
- LOW: [N] issues
- Phase 2 (pattern detection): [N] issues
- Phase 3 (completeness reasoning): [N] issues
- Phase 4 (compound findings): [N] issues

## Memory Health Score
[Phase 5 table]

## Verification Counts
- Timers: N created, M invalidated
- Observers: N added, M removed
- Tasks: N stored, M cancelled in cleanup
- Combine: N subscriptions, M with cancellable storage

## Issues by Severity

### [SEVERITY/CONFIDENCE] [Category]: [Description]
**File**: path/to/file.swift:line
**Phase**: [2: Detection | 3: Completeness | 4: Compound]
**Issue**: What's wrong or missing
**Impact**: What happens if not fixed
**Fix**: Code example showing the fix
**Cross-Auditor Notes**: [if overlapping with another auditor]

## Recommendations
1. [Immediate actions — CRITICAL fixes]
2. [Short-term — HIGH fixes and lifecycle cleanup]
3. [Long-term — architectural improvements from Phase 3 findings]
4. [Instruments verification — suggested profiling workflows]
```

## Output Limits

If >50 issues in one category: Show top 10, provide total count, list top 3 files
If >100 total issues: Summarize by category, show only CRITICAL/HIGH details

## False Positives (Not Issues)

- `weak var delegate` — Already safe
- Closures with `[weak self]` — Already safe
- Static/singleton timers (intentionally long-lived)
- One-shot timers with `repeats: false`
- Most SwiftUI callbacks (views are value types)
- Task captures where self is a struct (value type)
- Combine subscriptions stored in `Set<AnyCancellable>` or `AnyCancellable` property

## Field Crash Correlation

If the user has `.ips`, MetricKit, or legacy `.crash` text artifacts from the field (TestFlight, Xcode Organizer `.xccrashpoint` bundles, MetricKit payloads), symbolicate them before inferring the leak pattern. xcsym's `pattern_tag` flags the memory failure mode directly:

| pattern_tag | What the audit should look for |
|---|---|
| `jetsam_oom` | Unbounded collection growth, undisposed caches, large images retained in view hierarchy |
| `zombie_or_heap_corruption` | Use-after-free — missing `[weak self]` in a Task or closure, over-retained delegate |
| `bad_memory_access` | Dangling reference after deallocation — cross-reference Phase 2 Pattern 4 (delegate cycles) |

```bash
xcsym crash --format=summary <path-to-ips>
```

Use the `crashed_thread.frames` to localize which owner class needs deeper Phase 1 ownership mapping.

## Related

For Instruments workflows: `axiom-performance (skills/memory-debugging.md)` skill
For Memory Graph Debugger: `axiom-performance (skills/memory-debugging.md)` skill
For Task lifecycle issues found during audit: `axiom-concurrency` skill
For symbolicating field crashes (jetsam, heap corruption): `axiom-tools (skills/xcsym-ref.md)`