@jrieken Because this might be caused by a recent refactoring in 4d43287, I have pushed a change via 8dcfb37 to disable the emitter leak monitor for now.

@jrieken @bpasero Now that I saw how the monitor works (it is always enabled), and that 4d43287 tries to avoid reading Error.stack (presumably to avoid a perf hit), we might consider enabling the leak monitor only behind a --troubleshoot CLI flag.

We do this since a couple of years, what has changed is the lazy creation of the actual string (by holding a reference to the error). We can turn that back to be a string, esp. since the stacktrace value is used just after its creation. @alexdima I see how this consumes memory (more than before) but I fail to see leak here. Can you explain?

Using the original steps, there is now a reference to an array buffer, kept alive by a minimap instance, kept alive by an editor view instance, which is kept alive by something called StackFrameInfo, which I guess is an internal v8 class. All these objects are logically disposed, the original steps involve closing the editor.

Of note is that the editor core does not have any listeners to IKeybindingService.onDidUpdateKeybindings so I cannot explain why the _listeners list of IKeybindingService._onDidUpdateKeybindings would end up referencing an editor view instance.

Do you think that this leak always existed, even when reading Error.stack eagerly? What change should I try locally to simulate the old behavior?

Went back to eagerly getting the value of a stacktrace via new Error().stack. Still a mystery why the StackFrameInfo hold onto "random" thing tho.