Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 516018

Summary: Correctly report Tern errors when it fails to load
Product: [ECD] Orion Reporter: Tomer Ohana <ohana54>
Component: JS ToolsAssignee: Michael Rennie <Michael_Rennie>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P2 CC: steve_northover, tomero
Version: 14.0   
Target Milestone: 15.0   
Hardware: PC   
OS: Mac OS X   
See Also: https://github.com/eclipse/orion.client/pull/13
Whiteboard:
Attachments:
Description Flags
Test project
none
Updated test project none

Description Tomer Ohana CLA 2017-05-01 17:14:26 EDT
In ternWorkerCore.js, when Tern is loaded using the fallback option, it can still fail if there is a parsing error due to a problem in a definition file.
The regular startup is wrapped with try-catch, but the fallback function is not.
This will also cause a stack overflow because the startAndMessage function eventually calls itself if it fails.
I will submit a PR that will try to solve it.
Comment 1 Tomer Ohana CLA 2017-05-01 18:22:02 EDT
PR: https://github.com/eclipse/orion.client/pull/13
Comment 2 Steve Northover CLA 2017-05-02 17:47:23 EDT
Mike, please work with Tomer to get his pull request merged.  

Tomer, I noticed that he reformatted the file which is a no-no.  If the file has bad formatting, do a commit that fixes the formatting only, then another commit that fixes the problem.  This makes code changes easier to see and understand.
Comment 3 Steve Northover CLA 2017-05-02 17:51:58 EDT
Tomer, if you have not signed the Eclipse Committer Agreement, you need to do that for anything more than a few lines changes.

https://eclipse.org/contribute/
Comment 4 Tomer Ohana CLA 2017-05-02 19:35:06 EDT
Steve, I did the formatting change in a separate commit. The PR includes 2 commits, the formatting and the actual change.
Regarding the ECA, that's weird because I remember signing it.
I'll take care of it now.
Comment 5 Tomer Ohana CLA 2017-05-02 19:38:54 EDT
Apparently I have two users, I submitted the bug with my private user, and created the PR with my work user.
Anyway, I signed the ECA with my work user, which is the same email in GitHub.
Let me know if I need to do anything else.
Comment 6 Steve Northover CLA 2017-05-03 08:10:54 EDT
I'm sorry Tomer, I didn't look closely at the pull request.  Anyhow, Mike owns the review for this.
Comment 7 Michael Rennie CLA 2017-05-08 11:41:55 EDT
(In reply to Tomer Ohana from comment #0)
> In ternWorkerCore.js, when Tern is loaded using the fallback option, it can
> still fail if there is a parsing error due to a problem in a definition file.
> The regular startup is wrapped with try-catch, but the fallback function is
> not.
> This will also cause a stack overflow because the startAndMessage function
> eventually calls itself if it fails.
> I will submit a PR that will try to solve it.

Hi Tomer! Do you have some concrete steps to reproduce the problem? I was testing with a simple project (which I will attach) and when I introduce a typo in a definition - Tern does indeed fail to restart correctly - but the problem seems to be coming from the _getFile callback, and neither the old code nor your proposed fix seem to properly handle it.

See the _loadDef function (~line 794):

deferred.resolve(contents.length > 0 ? JSON.parse(contents) : Object.create(null));

when a def cannot be parsed the deferred is never resolved (or rejected) and the whole thing hangs waiting for it.

I would propose we trap the exception here and drop the bad def from being loaded - that way we can continue on to load any other "good" definitions.
Comment 8 Michael Rennie CLA 2017-05-08 11:44:02 EDT
Created attachment 268215 [details]
Test project

The project I was testing with. 

Simply import it and open the Test.js file.
Comment 9 Tomer Ohana CLA 2017-05-08 12:31:45 EDT
We encountered a case where the JSON was valid, but the Tern syntax was invalid so it failed (I'm sorry but I don't really remember what). In that case I think it should pass _loadDef and reach Tern.

Another thing I notice now is that I made a mistake in the bug report, we are using v12 and not v14, but the code that I fixed looks the same in both versions.

Note that we encountered the issue during development, with "hardcoded" definitions it obviously can't happen in production.
If I remember correctly, we messed around with the definition file to test type inference with promises and made a typo. Example syntax: "fn() -> +Promise[value=+void]".

I hope this helps :)
Comment 10 Michael Rennie CLA 2017-05-09 10:07:30 EDT
(In reply to Tomer Ohana from comment #9)
> We encountered a case where the JSON was valid, but the Tern syntax was
> invalid so it failed (I'm sorry but I don't really remember what). In that
> case I think it should pass _loadDef and reach Tern.
> 
> Another thing I notice now is that I made a mistake in the bug report, we
> are using v12 and not v14, but the code that I fixed looks the same in both
> versions.
> 
> Note that we encountered the issue during development, with "hardcoded"
> definitions it obviously can't happen in production.
> If I remember correctly, we messed around with the definition file to test
> type inference with promises and made a typo. Example syntax: "fn() ->
> +Promise[value=+void]".
> 
> I hope this helps :)

Thanks! I will try to make a test case for it.
Comment 11 Michael Rennie CLA 2017-05-09 10:32:15 EDT
Created attachment 268251 [details]
Updated test project

Here is an updated test project with various typos in the definition file.

Tern still starts correctly for me, which is likely because we have made many fixes since v12 around Tern properly forwarding exceptions back to Orion when it fails to load a definition. We also fixed our definition type parser to ignore "bad stuff" in defs that can't be correctly parsed.
Comment 12 Tomer Ohana CLA 2017-05-09 17:24:38 EDT
That's awesome! I think the PR is still good because it still fixes a potential stack overflow in case of an unforeseen error (fallback calling startAndMessage which can call fallback again...).
WDYT?
Comment 13 Michael Rennie CLA 2017-05-10 12:05:20 EDT
(In reply to Tomer Ohana from comment #12)
> That's awesome! I think the PR is still good because it still fixes a
> potential stack overflow in case of an unforeseen error (fallback calling
> startAndMessage which can call fallback again...).
> WDYT?

I don't think it would hurt to pro-actively try and prevent overflows :)

I think you will have to update the PR, as I released some code today that is causing conflicts (sorry about that).
Comment 14 Michael Rennie CLA 2017-06-16 13:02:00 EDT
(In reply to Tomer Ohana from comment #12)
> That's awesome! I think the PR is still good because it still fixes a
> potential stack overflow in case of an unforeseen error (fallback calling
> startAndMessage which can call fallback again...).
> WDYT?

Tomer, do you plan to update the PR so we can get it merged?
Comment 15 Tomer Ohana CLA 2017-06-16 14:05:41 EDT
Yes! I'm sorry, been swamped at work, I'll get to it in the next few days.
Comment 16 Tomer Ohana CLA 2017-06-16 17:45:08 EDT
Rebased the commits on current master, let me know if it's fine.
Comment 17 Michael Rennie CLA 2017-06-20 14:40:26 EDT
(In reply to Tomer Ohana from comment #16)
> Rebased the commits on current master, let me know if it's fine.

Merged with master, thanks again Tomer!
Comment 18 Tomer Ohana CLA 2017-06-21 01:16:21 EDT
Awesome, glad to help