formulahendry / vscode-auto-close-tag

Auto Close Tag for Visual Studio Code
https://marketplace.visualstudio.com/items?itemName=formulahendry.auto-close-tag
MIT License
178 stars 52 forks source link

Typing in img onLoad causes vs code helper to spike to 100% cpu usage. #70

Open DDKnoll opened 6 years ago

DDKnoll commented 6 years ago

For some reason, typing inside of the <img onLoad={typehere}/>jsx tag immediately causes my CPU to spike to 100% and freezes the editor for about 5 seconds. Disabling this extension fixes the issue.

auto_rename_max_cpu

atombender commented 6 years ago

I'm also seeing 100% CPU spikes when using this extension. Probably an infinite loop somewhere; it causes other extensions (e.g. ESLint) to stop working until the extension host process is killed. I've disabled almost all my extensions to narrow it down; CPU blow-up ceases to occur if I disable this one.

formulahendry commented 6 years ago

@DDKnoll @atombender If you disable all other extensions and only enable this extension, isthe CPU usage still high?

atombender commented 6 years ago

@formulahendry I have work to do, and many extensions I need to be productive, so that has not been an option. What I did was the reverse: I disabled extensions, one by one, until the problem stopped.

I just enabled the extension again, removed a closing tag in one of my React JSX files, and CPU went up to 100%. I was able to reduce the test case to this:

import React from 'react';

function render() {
  return (
    <TextField
      placeholder='Your password'
      type='password'
      disabled={busy}
      onChange={value => this.setState({password: value})}> **caret**
  );
}

Hitting the "auto close tag" keyboard shortcut with the caret at the end of the onChange line causes the problem consistently. However, the CPU only spikes for about 3-4 seconds, then goes back to normal. There must be some other edge cases that trigger longer loops. If I put back some of the code, this code seems to cause a permanent spike:

import React from 'react';

class LoginPanel extends React.Component {

  render() {
    return (
      <div className='LoginPanel'>
        <Form>
          <Fieldset>
            <Field label='Email'>
              <TextField
                ref={e => this._emailField = e}
                placeholder='Your email'
                disabled={busy}
                validator={value => (value != '' && !isValidEmail(value)) ? `Not a valid email address` : null}
                onChange={value => this.setState({email: value})}/>
            </Field>
            <Field label='Password'>
              <TextField
                placeholder='Your password'
                type='password'
                disabled={busy}
                onChange={value => this.setState({password: value})}> **caret**
            </Field>
          </Fieldset>
        </Form>
      </div>
    );
  }

}
formulahendry commented 6 years ago

Thanks @atombender for the code snippet!

GriffinSauce commented 6 years ago

My first gut feeling is that the core regex of the extension has a case of catastrophic backtracking. <([a-zA-Z][a-zA-Z0-9:\-_.]*)(?:\s+[^<>]*?[^\s/<>=]+?)*?\s?(\/|>) (minus the $ at the end)

Playing around with it on regex101.com might help find the issue more easily. As you can see it times out with the short snippet in @atombenders comment https://regex101.com/r/Zui65a/2

It would help to deconstruct the regex more, I admit not fully understanding every part, but by fudging around I found that removing the > from the arrow function prevents the timeout. So there's something going on the the quantifiers regarding the > character.

@formulahendry could you deconstruct/explain this part? (?:\s+[^<>]*?[^\s/<>=]+?)*?

hunhejj commented 6 years ago

Any update? With the March release of VSCode (1.22.1) I constantly ran into the above issue. Hence I had to disable the extension in the end.

caub commented 6 years ago

@DDKnoll I bet you're using SublimeText mode?

It's frequently crashing with it, maxing CPU usage

I guess the infinite loop is in getCloseTag

caub commented 6 years ago

certainly fixed by #87