Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explore extension host error spamming the core #22804

Closed
kieferrm opened this issue Mar 17, 2017 · 8 comments
Closed

Explore extension host error spamming the core #22804

kieferrm opened this issue Mar 17, 2017 · 8 comments
Assignees
Milestone

Comments

@kieferrm
Copy link
Member

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

@kieferrm kieferrm added this to the March 2017 milestone Mar 17, 2017
@kieferrm kieferrm self-assigned this Mar 17, 2017
@kieferrm kieferrm mentioned this issue Mar 20, 2017
58 tasks
@kieferrm
Copy link
Member Author

I created an extension (see https://github.com/kieferrm/vscode-22804). It provides the following commands:
screen shot 2017-03-20 at 8 10 50 am

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
Copy link
Member Author

//cc @jrieken

@jrieken
Copy link
Member

jrieken commented Mar 20, 2017

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
Copy link
Contributor

isidorn commented Mar 20, 2017

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
Copy link
Member

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
Copy link
Member

jrieken commented Mar 20, 2017

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

screen shot 2017-03-20 at 18 21 52

crazy-diag.cpuprofile.txt

@jrieken
Copy link
Member

jrieken commented Mar 20, 2017

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.

screen shot 2017-03-20 at 18 26 52

crazy-output.cpuprofile.txt

@isidorn
Copy link
Contributor

isidorn commented Mar 21, 2017

@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.

@jrieken jrieken reopened this Mar 21, 2017
@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 18, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants