VTI crashes with exit code 1 without any logs

[ktsn]

• I have searched through existing issues
• I have read through docs
• I have read FAQ

Info

• Platform: macOS 10.15.3
• VTI version: 0.0.2
• VS Code version: -

Problem

vti diagnostics crashes without any error logs on a larger project.

• number of .vue -> 134
• number of .ts -> 120

I couldn't catch any errors even though I set uncaughtexception and unhandledrejection even in vti source.

Reproducible Case

It's pretty hard to reproduce as it looks depends on the size of a project (maybe memory allocation related?) and the reproducible project is confidential.
I've got some memory report in the attached zip file.

https://drive.google.com/file/d/1zUKepNdxCH7Imk2zR7bHvArcGQ8MDmwn/view?usp=sharing

• Timeline.heaptimeline Memory allocation timeline through vti diagnostics
• Snapshot1.heapsnapshot Snapshot just after starting vti diagnostics
• Snapshot2.heapsnapshot Snapshot after 2-3 seconds of starting vti diagnostics
• Snapshot3.heapsnapshot Snapshot just before vti diagnostics crashes

[jackkoppa]

Hi @ktsn - I'm having the same exact experience. I added logging & breakpoints to both vti > cli.js, and vue-language-server > vls.js, but there are no JS exceptions being thrown before it exits with 1. In my case, for a small project, it will usually get through the 8 files that it needs to check, but fail right before the validation result is returned to vti > cli.js for the final file. Though there's some variation on when exactly the failure occurs, if I try the command 10 different times. And, every once in a while, it gets all the way through without errors

Will create a repro case repo

[jackkoppa]

@ktsn, @octref - this repo is a reliable reproduction on my machine. I'm under no illusions that you'll have the exact same experience on your machines, but if you have a few minutes to try, that'd be excellent.

https://github.com/jackkoppa/vti-failures-1699

Quick repro steps from the README, that are reliable on my machine:

git clone https://github.com/jackkoppa/vti-failures-1699.git
cd vti-failures-1699
npm ci
npm run vti

# fails

# Now, change one of the ComplexComponent files from .vue -> .txt
# thus removing it from vti observation, and run vti again
mv src/components/ComplexComponent4.vue src/components/ComplexComponent4.txt
npm run vti

# succeeds

# Finally, if you *still* see a failure message, we can try one more thing:
git checkout -- .
git clean -df
# Branch w/ even fewer vti-checked files
git checkout minimal-file-count-for-additional-testing
npm run vti

[dkonchekov]

Hi, @jackkoppa! I reproduced error on my machine with 2 more ComplexComponents (6 in total).

[dkonchekov]

Running vti with sudo fixes problem on my machine. @jackkoppa , @ktsn could you try?

System:

ProductName:	Mac OS X
ProductVersion:	10.15.3
BuildVersion:	19D76

[jackkoppa]

@dkonchekov - whoa! You're absolutely right!

I can run sudo npm run vti on the repo, and it worked without any issue! Without sudo, still fails.

Also tried sudo npm run vti on one of our private repos, with:

• 48 .vue files
• 32 .ts files

And had no issues, where the command had previously errored out quite quickly. Awesome!

I'm far from a process/memory allocation expert - I wonder what the best way to find the relevant upper bound is that sudo is removing?

[bahek2462774]

It happens to me as well. Working fine with sudo
sudo npm run vti. Otherwise, it fails.

[dkonchekov]

Here output of linux strace vti diagnostics in @jackkoppa repo:

1. with sudo: https://vti-1699.s3.amazonaws.com/output-sudo.txt
2. without sudo: https://vti-1699.s3.amazonaws.com/output.txt

[dkonchekov]

There is similar project https://github.com/Yuyz0112/vue-type-check that doesn't suffer this problem.

[ktsn]

Thanks @jackkoppa and @dkonchekov for providing simple reproduction and work around regarding sudo! I can reproduce both behavior as well. I'll take a look on the crash.

[diastremskii]

Hi! The issue was not the large projects, VTI was killed after 3s timeout on projects of any size because VS Code language server self-terminated.
I've opened a PR with a suggestion how we can fix it and more complete description of the problem. Would appreciate if someone could take a look.