VS Code crashes with minimap and bracket colorizer enabled on large file

[jvilk-stripe]

Does this issue occur when all extensions are disabled?: Yes/No

• VS Code Version: 1.62.1
• OS Version: Mac OS X 12.0.1

Steps to Reproduce:

1. Enable minimaps.
2. Enable the VS Code bracket colorizer.
3. Launch VS Code with --disable-extensions
4. Open a 5MB JavaScript file.
5. VS Code crashes (becomes unresponsive, prompts to reopen or wait)

I have attached a gzipped file which reproduces the issue:

big.js.gz

You may be wondering, "why on earth do we have a 5MB JavaScript file?" The answer... is codegen. :)

A simplish fix for us would be to let us disable minimap on large files.

[alexdima]

This did not crash for me and I couldn't find a problem with the minimap. On my machine, it allocates 3x 540KB buffers for the pixels, but otherwise it seems to be running fine. After a lot of waiting, I was even able to generate a heap snapshot.

@jrieken the OutlineModel stood out to me at 60MB and another 30MB are counted inside the Objects first row for an object referenced via a field called _requests. Reach out to me in the next couple of days if you want the saved heap snapshot (>50MB).

[jvilk-stripe]

OK, update on my end: This does not happen in an empty workspace.

It happens 100% of the time when I open VS Code to our monorepo and open the file:

code --disable-extensions ~/path/to/stripe/monorepo
# then, I open big.js

I have no other files open, just big.js. Is there any debug info I might be able to fetch for you?

[jvilk-stripe]

@alexdima Figured it out. Enable the bracket colorizer, and it reproduces!

{
  "editor.bracketPairColorization.enabled": true
}

I'll update the ticket above.

[gjsjohnmurray]

@jvilk-stripe are you able to update to latest Stable version, 1.63.2, then re-test?

[jvilk-stripe]

I just downloaded the latest stable version and it does not reproduce!

Sorry for the noise, everyone -- we delay the rollout of new versions internally. :)

[jrieken]

The _requests field is a LRU cache of the last few outline models. This is to ensure speedy outline/breadcrumbs while switching between files. Tho, it isn't very smart as the cache key includes the model version, meaning there will be entries kept in cache that won't ever be used again. I am planning some refactorings as part of #140557 and I can fix this too. Unsure about the model itself and if bytes should be squeezed or not

[jrieken]

Closing after fixing a couple of outlines related things

• don't cache outline for N-1 version of one model
• don't cache outline for disposed models
• keep only one copy in cache