Ewa
d19a2350f9
This PR add a new skill for detecting and removing memory leaks using take_memory_snapshot tool. Skill was based on authoritative material from own sources: * https://developer.chrome.com/docs/devtools/memory-problems * https://web.dev/articles/effectivemanagement as well as examples of memory leaks from public domain. It can be tested with https://github.com/devnook/mem-leak-example. Example prompt * A page running at localhost:3000 has memory issues when you click from home to contact tab and back. Can you fix it? The skill prefers using comparison tools like memlab instead of custom evaluate_script snippets to avoid directly reading of .heapsnpashot files to save context space and tokens. Fixes #1056 --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: Yusheng <113574546+yshngg@users.noreply.github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Alex Rudenko <OrKoN@users.noreply.github.com> Co-authored-by: Mathias Bynens <mathias@qiwi.be>
2.7 KiB
name, description
| name | description |
|---|---|
| memory-leak-debugging | Diagnoses and resolves memory leaks in JavaScript/Node.js applications. Use when a user reports high memory usage, OOM errors, or wants to analyze heapsnapshots or run memory leak detection tools like memlab. |
Memory Leak Debugging
This skill provides expert guidance and workflows for finding, diagnosing, and fixing memory leaks in JavaScript and Node.js applications.
Core Principles
- Prefer
memlab: Do NOT attempt to read raw.heapsnapshotfiles directly, as they are extremely large and will consume too many tokens. Always recommend and usememlabto process snapshots and identify leak traces. - Isolate the Leak: Determine if the leak is in the browser (client-side) or Node.js (server-side).
- Common Culprits: Look for detached DOM nodes, unhandled closures, global variables, event listeners not being removed, and caches growing unbounded. Note: Detached DOM nodes are sometimes intentional caches; always ask the user before nulling them.
Workflows
1. Capturing Snapshots
When investigating a frontend web application memory leak, utilize the chrome-devtools-mcp tools to interact with the application and take snapshots.
- Use tools like
click,navigate_page,fill, etc., to manipulate the page into the desired state. - Revert the page back to the original state after interactions to see if memory is released.
- Repeat the same user interactions 10 times to amplify the leak.
- Use
take_memory_snapshotto save.heapsnapshotfiles to disk at baseline, target (after actions), and final (after reverting actions) states.
2. Using Memlab to Find Leaks (Recommended)
Once you have generated .heapsnapshot files using take_memory_snapshot, use memlab to automatically find memory leaks.
- Read references/memlab.md for how to use
memlabto analyze the generated heapsnapshots. - Do not read raw
.heapsnapshotfiles usingread_fileorcat.
3. Identifying Common Leaks
When you have found a leak trace (e.g., via memlab output), you must identify the root cause in the code.
- Read references/common-leaks.md for examples of common memory leaks and how to fix them.
4. Fallback: Comparing Snapshots Manually
If memlab is not available, you MUST use the fallback script in the references directory to compare two .heapsnapshot files and identify the top growing objects and common leak types.
Run the script using Node.js:
node compare_snapshots.js <baseline.heapsnapshot> <target.heapsnapshot>
The script will analyze and output the top growing objects by size and highlight the 3 most common types of memory leaks (e.g., Detached DOM nodes, closures, Contexts) if they are present.