Explore extension host error spamming the core

[kieferrm]

Explore if the extension host can bring down the core using the API or through errors.

[kieferrm]

I created an extension (see https://github.com/kieferrm/vscode-22804). It provides the following commands:

The idea behind those commands are that an extension does not intentionally try to behave badly but that it is an unintentional outcome of how it is implemented. For example, it produces tons of output, exceptions, problems, etc.

Findings so far ordered by severity:

• Flooding the core with output to output channels leads to a temporary freeze of the UI. Depending on the number of message written to the channel the UI can freeze for minutes. The user experiences the "Windows is not responding" dialog.
• Flooding the core with problems leads to a temporary freeze of the UI. If an extension creates too many problems, the extension host dies with out-of-memory. I have also seen internal errors when creating more than 5000 problems, but this is not a reliably reproducible issue.
• There are no issues when an extension generates thousands of exceptions.
• There are no issues when an extension floods terminals with thousands of output messages.
• Combining several types of "flooding" is purely additive, i.e. the user experience is not much worse.

[kieferrm]

//cc @jrieken

[jrieken]

cc @isidorn for the output freeze which might be due to excessive (text) model updating and @sandy081 for the diagnostics view.

have also seen internal errors when creating more than 5000 problems,

@kieferrm There should be some guard that we don't produce too many diagnostics per resource but those checks are easy to around

[isidorn]

We had previous issue reports regarding the slow output and we are currently already protecting ourselfs from excessive text model updating.

More details can be found in this issue which also links to some other related issues #12265

[sandy081]

If I remember we fixed this performance issue with diagnostics when the extension created too many diagnostics - #11976. I will investigate the root-cause of the issue happening here

[jrieken]

For crazy diagnostics we spend most time in receiving, esp parsing, data... @sandy081 is off the hook ;-)

crazy-diag.cpuprofile.txt

[jrieken]

48seconds in OutputService#append. @isidorn wins the the prize... Basically, this is all due to us making a lot of new strings and calling substr very often. @isidorn let's sit and make this better.

crazy-output.cpuprofile.txt

[isidorn]

@jrieken and me have improved the performance of appending to output channels by reducing the number of creating new strings. We now use a data structure which handles appending a compute a delta of an output in a more efficent way.
Though when bombarding the output with 100000 messages vscode will still freeze for a couple of seconds due to the most time being spent in sending json objects around.