ios-memgraph-leaks

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

iOS Memgraph Leaks

iOS Memgraph 内存泄漏排查

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.

使用该技能可通过模拟器运行进程或已有的

.memgraph

文件排查iOS内存泄漏问题。若任务同时需要模拟器构建、安装、启动、UI驱动、日志或截图操作，可搭配

../ios-debugger-agent/SKILL.md

使用。

Core Workflow

核心流程

Build, launch, and drive the exact flow that should release objects.
Capture a memgraph from the running simulator process with
```
scripts/capture_sim_memgraph.sh
```
.
Summarize leaks with
```
scripts/summarize_memgraph_leaks.py
```
.
For each app-owned leaked type, inspect ownership with
```
leaks --traceTree=<address> <file.memgraph>
```
and grouped leak evidence.
Make the smallest root-cause patch, then recapture the same flow on the same simulator when possible.
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.

构建、启动应用，并执行会触发对象释放的特定流程。
使用
```
scripts/capture_sim_memgraph.sh
```
从运行中的模拟器进程捕获memgraph文件。
通过
```
scripts/summarize_memgraph_leaks.py
```
汇总泄漏信息。
针对每个应用所属的泄漏类型，使用
```
leaks --traceTree=<address> <file.memgraph>
```
检查对象所有权关系，并整理分组后的泄漏证据。
制定最小化的根因修复补丁，尽可能在同一模拟器上重新执行相同流程并捕获memgraph。
提交修复证明：修复前后的泄漏数量、已消失的根类型、剩余泄漏情况、memgraph文件路径，以及测试/构建结果。

仅通过更小的memgraph文件不能直接宣称泄漏已修复。可信的修复需解释导致对象无法释放的所有权路径，并证明修复后该路径或类型已消失。

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.

优先从用于复现问题的模拟器中捕获。先获取模拟器UDID和应用Bundle Identifier，再捕获运行中的应用：

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"

不要从目标应用仓库的

pwd

推导

SKILL_DIR

；已安装的插件通常位于被调试应用的外部。将捕获的文件存储在运行时专属的临时文件夹或用户指定的文件夹中，而非

SKILL_DIR

目录下。

若无法找到进程，请确认Bundle Identifier是否正确，并使用

xcrun simctl spawn "$SIM" launchctl list

检查运行中的标签。

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.

汇总已有的memgraph文件：

bash

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

谨慎使用

--trace-limit

参数。追踪树是有用的根因证据，但大型memgraph文件可能会产生冗余输出。如果追踪树显示

Found 0 roots referencing

，则将其视为不可达/自保留的泄漏候选对象，使用汇总结果中的分组泄漏树或

leaks --groupByType <file.memgraph>

来识别保留字段和负载链。

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.

在泄漏输出或追踪结果中识别首个应用所属的泄漏类型。
确定对象的预期生命周期：进程级、会话级、账户级、视图级、请求级或任务级。
除非原本的预分配违反了预期生命周期，否则将延迟分配视为作用域缩小，而非泄漏修复。
通过
```
traceTree
```
所有权路径或独立复现案例来证明保留循环的存在。
对于不可达/自循环泄漏，
```
traceTree
```
可能没有根路径；使用
```
leaks --groupByType
```
结合源码验证来找到自保留的关联。
不能仅因总泄漏数量减少就宣称修复成功；需证明特定类型或路径已消失。
区分真实的根因分支与候选/冗余分支。
优先删除保留关联，而非添加宽泛的清理代码。

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.

一份有效的泄漏报告应包含：

具体的测试流程、模拟器及应用构建版本
memgraph文件和汇总报告的路径
应用所属的泄漏类型及数量
至少一条所有权路径；若对象无法从根节点访问，则需提供分组泄漏树证据
最小化的建议或已实施的保留关联修复方案
修复前后的对比证据

若memgraph仅显示框架/运行时的冗余信息，请如实说明，并建议进行更精准的捕获，而非虚构应用泄漏问题。