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 とアプリのバンドル識別子を特定してから、実行中のアプリをキャプチャします。

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 の下ではなく、実行ごとの一時フォルダーまたはユーザーが選択したフォルダーに保存してください。

プロセスが見つからない場合は、バンドル識別子を確認し、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 と要約のパス
  • アプリ所有のリーク型と件数
  • 少なくとも 1 つの所有経路、またはオブジェクトがルートから到達不能な場合はグループ化されたリークツリーの証拠
  • 提案または適用した、保持参照に対する最小限の修正
  • 修正を行った場合は修正前後の証拠

memgraph にフレームワーク／ランタイムのノイズしか表示されない場合は、その旨を伝え、アプリのリークをでっち上げるのではなく、次に対象を絞ったキャプチャを行うよう提案してください。

コメント

Markdown 対応