-
Notifications
You must be signed in to change notification settings - Fork 0
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
[CLOSED] Code hints occasionally die and Brackets helper pegs one CPU core #5355
Comments
Comment by peterflynn This started for me within the past 1-2 weeks, but that may also coincide with one of our recent Tern updates. |
Comment by 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. |
Comment by peterflynn Finally got this to happen with dev tools open! It's stuck in acorn_loose, in readToken()'s catch block, catching a 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 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. |
Comment by 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. |
Comment by 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) |
Comment by peterflynn Finally -- recipe to reproduce on clean master:
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...). |
Comment by dangoor I'll take this. |
Comment by dangoor I'll call this medium priority, given your "not being noticed by other users" description. |
Comment by 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. |
Comment by 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. |
Comment by dangoor
|
Comment by njx Nominating for sprint 35 |
Comment by 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. |
Comment by peterflynn I think PR #6068 fixes the other half of this. |
Comment by peterflynn Marking FBNC to me -- will verify later that #6068 and #6064 do indeed fix the two halves of this |
Comment by pthiess
|
Comment by kethinov I'm still experiencing this in 36 on OS X 10.9.1. |
Comment by peterflynn Both halves confirmed -- closing.
|
Comment by kethinov This issue is still open and accurately describes what I'm seeing: adobe/brackets#5847 I will post detailed steps to reproduce in that thread. |
Issue by peterflynn
Monday Nov 04, 2013 at 22:42 GMT
Originally opened as adobe/brackets#5847
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.
The text was updated successfully, but these errors were encountered: