chromedevtools/memory-leak-debugging

Speicherleck-Debugging

Dieses Skill bietet fachkundige Anleitungen und Workflows zum Auffinden, Diagnostizieren und Beheben von Speicherlecks in JavaScript- und Node.js-Anwendungen mit den Chrome DevTools MCP-Tools.

Voraussetzungen

Die erweiterten Speicher-Debugging-Tools (compare_heapsnapshots, get_heapsnapshot_details usw.) sind nur verfügbar, wenn der Server mit dem Flag --memoryDebugging gestartet wurde. Prüfe zuerst, ob diese Tools verfügbar sind; falls nicht, versuche, die MCP-Konfigurationsdatei zu lesen, um festzustellen, ob --memoryDebugging aktiviert ist.

Kernprinzipien

• MCP-Speichertools bevorzugen: Versuche NICHT, rohe .heapsnapshot-Dateien direkt zu lesen, da sie extrem groß sind und zu viele Tokens verbrauchen. Verwende stattdessen die Chrome DevTools MCP-Heap-Snapshot-Tools, um Snapshots zusammenzufassen, zu vergleichen und zu untersuchen.
• Das Leck isolieren: Stelle fest, ob das Leck im Browser (clientseitig) oder in Node.js (serverseitig) auftritt.
• Häufige Übeltäter: Achte auf losgelöste DOM-Knoten, unbehandelte Closures, globale Variablen, nicht entfernte Event-Listener und unbegrenzt wachsende Caches. Hinweis: Losgelöste DOM-Knoten sind manchmal beabsichtigte Caches; frage immer den Benutzer, bevor du sie auf null setzt.
• Geladene Snapshots schließen: Heap-Snapshots können groß sein. Verwende nach Abschluss einer Untersuchung close_heapsnapshot für jeden geladenen Snapshot, um den vom MCP-Server belegten Speicher freizugeben.

Workflows

1. Snapshots erfassen

Wenn du einen Speicherleck in einer Frontend-Webanwendung untersuchst, verwende die chrome-devtools-mcp-Tools, um mit der Anwendung zu interagieren und Snapshots zu erstellen.

• Verwende seitenspezifische Tools wie click, navigate_page, fill usw. (mit Angabe von pageId), um die Seite in den gewünschten Zustand zu versetzen.
• Setze die Seite nach den Interaktionen wieder in den ursprünglichen Zustand zurück, um zu sehen, ob Speicher freigegeben wird.
• Wiederhole die gleichen Benutzerinteraktionen 10 Mal, um das Leck zu verstärken.
• Verwende take_heapsnapshot (mit pageId), um .heapsnapshot-Dateien auf der Festplatte zu speichern – zu Beginn (Baseline), nach den Aktionen (Ziel) und nach dem Zurücksetzen (Endzustand).

2. Snapshots vergleichen

Sobald du mit take_heapsnapshot .heapsnapshot-Dateien erstellt hast, vergleiche sie mit den Chrome DevTools MCP-Speichertools.

• Beginne mit get_heapsnapshot_summary für jeden Snapshot, um zu bestätigen, dass die Dateien geladen werden, und um die Gesamtsummen auf hoher Ebene zu vergleichen.
• Verwende compare_heapsnapshots, um Baseline- und Ziel-Snapshots zu vergleichen. Starte ohne classIndex für den Zusammenfassungsdiff und fordere dann nur bei verdächtigem Wachstum detaillierte Klassen-Diffs an, indem du classIndex angibst.
• Nutze die Zusammenfassungsausgabe von compare_heapsnapshots, bevor du dich mit spezifischen Knoten-IDs befasst.

3. Retainer und Dominator-Ketten untersuchen

Wenn eine Klasse oder ein Objekttyp unerwartet wächst, untersuche die Retaining-Kette und die Dominatoren mit den MCP-Tools, bevor du den Code änderst.

• Verwende get_heapsnapshot_class_nodes, um Instanzen der verdächtigen Klasse aufzulisten.
• Verwende get_heapsnapshot_retainers, get_heapsnapshot_retaining_paths, get_heapsnapshot_dominators und get_heapsnapshot_edges, um zu verstehen, warum repräsentative Knoten noch erreichbar sind.
• Verwende get_heapsnapshot_object_details mit einer bestimmten nodeId, um detaillierte Objektmetadaten (Größe, Typ, Entfernung und DOM-Abhängigkeit) abzurufen.
• Verwende get_heapsnapshot_duplicate_strings, wenn das Wachstum von Zeichenketten den Diff dominiert.
• Lies references/common-leaks.md für Beispiele häufiger Speicherlecks und deren Behebung, nachdem der Retaining-Pfad auf Anwendungscode verweist.

4. Erweiterte Analyse und kategorisierte Filter

Verwende die integrierten MCP-Speichertools und Filter, um spezifische Leckkategorien direkt zu identifizieren, ohne externe Tools.

• Verwende get_heapsnapshot_details oder get_heapsnapshot_class_nodes mit filterName, um häufige Leckursachen gezielt anzusteuern:
  • objectsRetainedByDetachedDomNodes: Identifiziert losgelöste DOM-Elemente, die im Speicher gehalten werden.
  • objectsRetainedByEventHandlers: Identifiziert Objekte, die durch nicht entfernte Event-Listener am Leben gehalten werden.
  • objectsRetainedByContexts: Identifiziert Objekte, die in Closures oder Ausführungskontexten gefangen sind.
  • objectsRetainedByConsole: Identifiziert Objekte, die durch Konsolenprotokollierung zurückgehalten werden.