Code hints occasionally die and Brackets helper pegs one CPU core

[peterflynn]

I've been seeing this fairly often locally -- about once a day. My fan will start spinning up, and one of the Brackets.exe processes is using 12-13% CPU (1/8th, i.e. one logical core). Memory usage stays basically flat but with a high page-fault rate, so it seems like the Tern-worker thread is in an infinite loop churning through, but not leaking, memory. Code hints in newly-opened stop working at this point, but the Brackets UI remains responsive.

This typically happens while I'm viewing completely typical files in the Brackets src code, like ProjectManager. But I can never get consistent steps to reproduce.

One thing I still need to figure out: if this happens only on the file-system branch, or on master too.

[peterflynn]

This started for me within the past 1-2 weeks, but that may also coincide with one of our recent Tern updates.

[peterflynn]

When it gets in this state, opening a dev tools instance on the tern-worker thread just brings up a blank window -- again suggesting that thread is hung. I tried bringing up dev tools in advance and waiting for the hang to come back, and it appears as if the dev tools window automatically closes itself when you get into that state. Need to pay more attention to see if that's really correlated...

Edit: the 'auto-closing' thing was a red herring. The code hints extension kills the worker thread & starts a new one almost any time you switch files, and any time the worker thread dies its dev tools window closes. So you have to be very vigilant about re-opening dev tools on the worker thread all the time.

[peterflynn]

Finally got this to happen with dev tools open!

It's stuck in acorn_loose, in readToken()'s catch block, catching a SyntaxError {pos: NaN, loc: Object, raisedAt: NaN}. But get this: at the bottom of the stack, we're in tern-worker's handleUpdateFile() for a non-JS file (my "SCRUM.txt" notes file). Trying to parse that sucker as JS could lead to all sorts of pathological cases for Acorn.

The state of ensureFile() in tern.js makes it clear the file was not previously known to Tern, so I'm betting there's some sort of race condition on our end where you switch away from a JS file and start making edits in the TXT file before the code hinter has caught up with the fact that you're no longer in a JS file (CC @RaymondLim, although this could be a bug someplace like ScopeManager too).

There's still the issue that Acorn infinite-loops when trying to parse this particular text, but now that I have a (probable) testcase that'll be easy to file as a separate bug.

[peterflynn]

The debugger is basically borked (dev tools never seems to work right if you pause inside an infinite loop), so it's not really possible to step through the execution. But from repeatedly pausing/unpausing and checking the stack, I'm pretty confident that's where it's stuck, anyway.

[peterflynn]

And the Tern demo page does indeed hang if I feed it that same text (debugger gets borked there too, though not as badly)

[peterflynn]

Finally -- recipe to reproduce on clean master:

1. Open the Tern-crasher text file as 1st item in working set
2. Open DocumentManager as 2nd (any JS file will do afaict though)
3. Place cursor anywhere you could type code on DocumentManager
4. Type "a"
5. Press Ctrl+Tab to switch to text file (you can either leave the code hints popup open or press Esc first to close it -- bug will repro either way)
6. Press Ctrl+Tab to switch back to JS file

Result: worker thread pegs a CPU core

Without a "bad" text file I suspect there are no symptoms of hitting this, hence it not being noticed by other users. But you can still confirm the wrong file is getting passed to Tern by putting a breakpoint in ScopeManager.updateTernFile(). (That function is actually never called with the real JS file afaict, so I have no idea what it's supposed to be fore...).

[dangoor]

I'll take this.

[dangoor]

I'll call this medium priority, given your "not being noticed by other users" description.

[dangoor]

Can you share the tern-crashing text file in a gist or something? I may want to file a bug against Tern (or Acorn) because it really should be able to recover from invalid input without spinning out of control.

[ivyfae]

I'm having what I think is the same issue. I used the Sprint 33 installer and did not have any version installed before that.

It seems that I press CTRL+Space, nothing happens, then while I'm off in Chrome (not live preview), Brackets will crash.

[Edit] Not sure if you want this removed, but it looks like the problem was caused by me having multiple versions of the same large .js in my lib folder. I removed the old versions and the minified current version and code hints came back.

[dangoor]

@lalanotlistening The code hinting system does have a way to exclude directories. Take a look at the configuration section of the JavaScript Code Hints page.

[njx]

Nominating for sprint 35

[peterflynn]

I boiled down my particular text file into a minimal Acorn testcase, filed here: acornjs/acorn#82.

There is still work to do on our end, though: we shouldn't be feeding Tern non-JS files in the first place. That seems like it should be easy to track down by breakpointing ScopeManager.updateTernFile() and seeing why it's getting called.

[peterflynn]

I think PR #6068 fixes the other half of this.

[peterflynn]

Marking FBNC to me -- will verify later that #6068 and #6064 do indeed fix the two halves of this

[pthiess]

@peterflynn Can we close this, Peter?

[kethinov]

I'm still experiencing this in 36 on OS X 10.9.1.

[peterflynn]

Both halves confirmed -- closing.

@kethinov Can you please file a new bug with as many details as possible? If you could share the code you're working on that'd be ideal. If not, the best approach is to make a copy of your project and remove bunches of files at a time until the issue goes away. That way you can narrow down which file is triggering the problem, and from there you can follow a similar approach within the file to narrow down what construct in the code is causing the problem. That should let you boil it down to a small enough code snippet that you can share in a bug report (renaming variables to anonymize it, etc.).

[kethinov]

This issue is still open and accurately describes what I'm seeing: #5847

I will post detailed steps to reproduce in that thread.