How a Hidden fetch Interception Caused Memory Leaks in FLV Live Streams (and How to Fix It)

Phenomenon

During IMWebConf 2020 live streaming, the Tencent Classroom page crashed when playing an FLV stream. The issue was severe, and the following describes the investigation and fix.

Investigation Process

Identified as Memory Leak

Crash was found to be caused by memory leak rather than network issues.

Stable Reproduction

Audio‑video team reproduced the crash with several test pages:

Blank test page: XHR request for FLV resource, memory grows then stabilizes at ~50 MB, no crash.

Blank test page: using flv.js to pull stream without playback, memory fluctuates around 200 MB, no crash.

Blank test page: using flv.js to pull and play, memory fluctuates around 200 MB, no crash.

Blank test page: using flv.js with same parameters as classroom page, memory fluctuates around 200 MB, no crash.

Sample page: using loki‑player in FLV mode, memory spikes and crashes.

Sample page: using imweb‑tcplayer wrapper, memory spikes and crashes.

Blank test page: using tcplayer to pull and play, memory stays stable, no crash.

Sample page: using flv.js with eruda, still crashes.

The issue differs from typical JavaScript heap leaks.

Memory debugging tools showed no problem, but Task Manager displayed rapid memory growth in the tab.

Narrowing Code Scope

Comparison of code differences suggested the leak was related to network interception logic in an internal reporting tool.

Both the eruda debugging tool and the player’s internal reporting module hijack network requests; ordinary users cannot use eruda, so the problem lies in the internal reporting tool.

In Chrome, network requests are implemented via IPC using shared memory.

Our multi‑process application can be viewed in three layers. At the lowest layer is the Blink engine which renders pages. Above that are the renderer processes (one per tab), each containing a Blink instance. The browser process manages all renderers and controls all network accesses.

Renderer processes read request/response data from the browser process via IPC, which uses shared memory.

According to Chrome’s memory metrics, shared memory counted as swapped memory, which appears in the Task Manager.

Fix

The fix introduces a whitelist filter that only records response bodies of types application/json, text/plain, and text/xml, excluding video types.

const defaultOpts = {
  // whether to record response content whitelist/blacklist
  resContentTypePatterns: {
    includes: [/application\/json/, /text\/xml/, /text\/plain/],
    excludes: [/video/],
  },
};
if (multiMatch(loggerFetch.resContentType, defaultOpts.resContentTypePatterns)) {
  // ...
}

Conclusion

The experience reminds us to treat code that hijacks global methods with caution and to implement robust fallback logic, ensuring service stability and reliability.

Monitoring memory leaks in core audio‑video pages remains a challenging task for the team.