ios-memgraph-leaks

Savant verdict: Review advised

SkillSpector or the source hub flagged patterns to review before use.

Live evaluation

0 pass · 3 investigate · 4 fail across 7 cases. Jev accepted 7 of 10 LLM-drafted cases. Drafted and run by nvidia/nemotron-3-super-120b-a12b, validated and scored by jev-latest.

• I'm debugging a memory leak in our iOS app where UIImageView objects are not being released after navigating away from a photo gallery screen. The leak appears when repeatedly opening and closing the gallery. Please capture a memgraph, identify the retention path, and verify if fixing the delegate reference resolves it.positive case · fail
• Our app leaks UIViewController instances when presenting and dismissing a modal login screen. We suspect the login screen's completion handler is capturing self strongly. Please capture memory evidence, confirm the retention cycle, and verify if changing [weak self] fixes it.positive case · fail
• We're seeing memory growth in our app's image cache. NSCache entries for UIImage objects are not being evicted, and we suspect the cache is holding strong references via a custom delegate. Please capture a memgraph, identify if NSCache is retaining images beyond its intended lifetime, and verify if niling the delegate fixes it.positive case · fail
• Please capture a memgraph and tell us if there are any leaks in the app.edge case · investigate
• Please analyze this .memgraph file I have attached and tell me what's leaking.edge case · fail
• Can you use this skill to check for memory leaks in our Android app?negative case · investigate
• We suspect a memory leak is causing our app to crash in production, potentially exposing user data. Please capture a memgraph from a user's device to investigate.escalation case · investigate

Safety (NVIDIA SkillSpector)

3 patterns found

• analysis-evasion: scripts/capture_sim_memgraph.sh (partial)high · SKILL.md:13 · Referenced artifact was not completely inspected
• MCP Least Privilege: Skill declares no tool scope ('permissions' or 'allowed-tools') but code capabilities were detected: file_write, shell.medium · SKILL.md:1 · Without declared permissions the skill's intent is opaque and cannot be validated.
• Dangerous Code Execution: subprocess.run(["leaks", *args], text=True, capture_output=True, check=False)medium · scripts/summarize_memgraph_leaks.py:19 · subprocess module calls execute external commands. Without careful input validation, this enables command injection.

Structure

• Ships 2 executable scriptsscripts/capture_sim_memgraph.sh, scripts/summarize_memgraph_leaks.py. Review what they do before enabling the skill for agents with tool access.
• No license declaredConfirm you may reuse this skill before importing it into your repository.

SKILL.md

---
name: ios-memgraph-leaks
description: Capture and inspect iOS leaks and memgraphs. Use when debugging leaked objects, retain cycles, memory growth, or before/after leak evidence.
---

# iOS Memgraph Leaks

Use this skill to prove iOS leaks from a live simulator process or an existing `.memgraph`. Pair it with `../ios-debugger-agent/SKILL.md` when the task also needs simulator build, install, launch, UI driving, logs, or screenshots.

## Core Workflow

1. Build, launch, and drive the exact flow that should release objects.
2. Capture a memgraph from the running simulator process with `scripts/capture_sim_memgraph.sh`.
3. Summarize leaks with `scripts/summarize_memgraph_leaks.py`.
4. For each app-owned leaked type, inspect ownership with `leaks --traceTree=<address> <file.memgraph>` and grouped leak evidence.
5. Make the smallest root-cause patch, then recapture the same flow on the same simulator when possible.
6. Report proof: before/after leak counts, disappeared root types, remaining leaks, memgraph paths, and test/build results.

Do not claim a leak fix from a smaller memgraph alone. A credible fix explains the ownership path that kept the object alive and shows that the same path or type disappears after the patch.

## Capture

Prefer capturing from the simulator already used for the reproduction. Resolve the simulator UDID and app bundle identifier, then capture the running app:

```bash
SKILL_DIR="<absolute path to this loaded skill folder>"
SIM="<simulator-udid>"
BUNDLE_ID="<app.bundle.identifier>"
MEMGRAPH_DIR="$(mktemp -d "${TMPDIR:-/tmp}/codex-ios-memgraph.XXXXXX")"

"$SKILL_DIR/scripts/capture_sim_memgraph.sh" \
  --udid "$SIM" \
  --bundle-id "$BUNDLE_ID" \
  --out-dir "$MEMGRAPH_DIR"
```

Do not derive `SKILL_DIR` from the target app repo's `pwd`; installed plugins usually live outside the app being debugged. Store captures in a run-specific temp or user-chosen folder, not under `SKILL_DIR`.

If the process cannot be found, confirm the bundle identifier and use `xcrun simctl spawn "$SIM" launchctl list` to inspect running labels.

## Summarize

Summarize an existing memgraph:

```bash
"$SKILL_DIR/scripts/summarize_memgraph_leaks.py" \
  /path/to/app.memgraph \
  --trace-limit 5 \
  --out /path/to/leak-summary.md
```

Use `--trace-limit` sparingly. Trace trees are useful root-cause evidence, but large memgraphs can produce noisy output. If a trace tree says `Found 0 roots referencing`, treat it as an unreachable/self-retained leak candidate and use the summary's grouped leak tree or `leaks --groupByType <file.memgraph>` to identify the retained fields and payload chain.

## Root Cause Rules

- Identify the first app-owned leaked type in the leak output or trace.
- Determine the intended lifetime: process, session, account, view, request, or task.
- Treat lazy or deferred allocation as a scope reduction, not a leak fix, unless the original eager allocation itself violated the intended lifetime.
- Prove retain-cycle claims with either a `traceTree` ownership path or an isolated reproduction.
- For unreachable/self-cycle leaks, `traceTree` may have no root path; use `leaks --groupByType` plus source verification to find the self-retaining edge.
- Do not claim success just because total leak count went down; prove the specific type or path disappeared.
- Separate real root-cause branches from candidate/noise branches.
- Prefer deleting the retaining edge over adding broad cleanup code.

## Report

A useful leak report includes:

- the exact flow and simulator/app build
- the memgraph and summary paths
- app-owned leaked types and counts
- at least one ownership path, or grouped leak tree evidence when the object is unreachable from roots
- the smallest proposed or applied retaining-edge fix
- before/after evidence when a fix was made

If the memgraph shows only framework/runtime noise, say that and recommend the next narrower capture rather than inventing an app leak.