# Diagnose a Memory Leak in a JavaScript Web Application A long-running JavaScript web application steadily consumes more memory after users repeat a particular workflow. Explain how you would reproduce, isolate, diagnose, and verify a fix for the leak using browser tooling, including Chrome DevTools or the Chrome DevTools Protocol. Your answer should distinguish a true leak from temporary allocation or a cache that reaches a stable bound. Discuss how you would use heap comparisons and retaining paths to connect growing memory to application code. ### Constraints & Assumptions - The leak appears in a repeatable user workflow, but the responsible component is not known. - Garbage collection timing is nondeterministic, so one high memory reading is not sufficient evidence. - The investigation must preserve enough observability to compare the same workflow before and after a fix. ### Clarifying Questions to Ask - Does memory grow in the browser heap, DOM-node count, GPU resources, network buffers, or the server process? - Which browser version, route, and user workflow reproduce the growth most reliably? - Does memory fall after navigating away, closing a modal, or forcing garbage collection in a diagnostic build? ```hint Compare equivalent checkpoints Capture a baseline, repeat one workflow several times, return to the same idle state, and compare snapshots by retained size and object-count delta. ``` ```hint Follow ownership, not just allocation The object type that grows may be a symptom; its retaining path shows the listener, closure, timer, cache, or global collection keeping it alive. ``` ### What a Strong Answer Covers - A deterministic reproduction loop with stable checkpoints and memory measurements. - Heap snapshots, allocation timelines, detached DOM inspection, and retaining-path analysis. - Isolation by disabling or narrowing components while keeping the workflow constant. - Common browser leak sources such as listeners, timers, subscriptions, closures, and unbounded caches. - Verification that post-fix memory returns to a stable plateau across repeated runs. ### Follow-up Questions - How would you automate the reproduction and heap capture through the Chrome DevTools Protocol? - What evidence would distinguish an intentionally bounded cache from a leak? - How would you investigate a leak that reproduces only in production traffic?