mcpField
I
ios-memgraph-leaks

ios-memgraph-leaks

github.com/openai开发7.6k1.2k 次安装3 周前更新
代码仓库

关于 ios-memgraph-leaks

iOS Memgraph Leaks 是用于调查运行中的 iOS 模拟器进程或现有 .memgraph 文件中内存泄漏的技能。它指导开发者采集数据、汇总泄漏、分析对象持有路径、实施针对性修复并提供前后证据。

主要功能

  1. 01采集模拟器 memgraph
  2. 02汇总泄漏数据
  3. 03检查对象持有路径
  4. 04识别应用自身泄漏类型
  5. 05重新采集以验证修复
  6. 06报告修复前后证据

适用场景

  1. 01调查模拟器应用流程中的泄漏
  2. 02分析现有 .memgraph 文件
  3. 03确认针对性修复是否消除了泄漏

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/openai/plugins --skill ios-memgraph-leaks

安装后在 Claude Code 中输入/ios-memgraph-leaks确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

agents/
openai.yaml
scripts/
capture_sim_memgraph.sh
summarize_memgraph_leaks.py

详细介绍

iOS Memgraph 泄漏

使用此技能从正在运行的模拟器进程或现有的 .memgraph 中证实 iOS 泄漏。如果任务还需要构建模拟器应用、安装、启动、操作 UI、查看日志或截图，请结合 ../ios-debugger-agent/SKILL.md 使用。

核心工作流

  1. 构建并启动应用，然后操作应释放对象的确切流程。
  2. 使用 scripts/capture_sim_memgraph.sh 从正在运行的模拟器进程捕获 memgraph。
  3. 使用 scripts/summarize_memgraph_leaks.py 汇总泄漏。
  4. 对于每种由应用持有的泄漏类型，使用 leaks --traceTree=<address> <file.memgraph> 和分组泄漏证据检查所有权。
  5. 采用改动最小的根因修复，然后尽可能在同一模拟器上重新捕获相同流程。
  6. 提供证据报告：修复前后的泄漏数量、消失的根类型、剩余泄漏、memgraph 路径以及测试和构建结果。

仅凭 memgraph 变小，不要声称泄漏已修复。可信的修复说明应解释对象因何种所有权路径而存活，并证明修复后相同路径或类型已消失。

捕获

优先从用于复现问题的模拟器捕获。解析模拟器 UDID 和应用的 bundle identifier，然后捕获正在运行的应用：

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 检查正在运行的标签。

汇总

汇总现有的 memgraph：

"$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> 找出被保留的字段和负载链。

根因规则

  • 在泄漏输出或跟踪中找出首个由应用持有的泄漏类型。
  • 确定预期的生命周期：进程、会话、账户、视图、请求或任务。
  • 将惰性或延迟分配视为缩小作用域，而非修复泄漏；除非原先的急切分配本身违反了预期的生命周期。
  • 使用 traceTree 所有权路径或隔离复现来证实保留环的判断。
  • 对于不可达或自环泄漏，traceTree 可能没有根路径；使用 leaks --groupByType 并核对源代码，找出自保持的引用边。
  • 不要仅因泄漏总数下降就声称修复成功；应证明特定类型或路径已消失。
  • 区分真实根因分支与候选项或噪声分支。
  • 优先删除造成保留的引用边，而不是添加范围宽泛的清理代码。

报告

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

  • 确切的操作流程以及模拟器和应用的构建信息
  • memgraph 和摘要的路径
  • 由应用持有的泄漏类型及数量
  • 至少一条所有权路径；如果对象无法从根到达，则提供分组泄漏树证据
  • 拟议或已应用的、改动最小的保留引用边修复
  • 修复前后的证据（如进行了修复）

如果 memgraph 中只有框架或运行时噪声，请明确说明，并建议进行更精确的下一次捕获，而不要臆造应用泄漏。

评论

支持 Markdown