[Bug?]: Typescript 5 Language server + pnp - No file descriptors available #5460
Comments
|
Two related issues that were reported in VSCode itself:
I'm also experiencing this, using Typescript 4.9.4. I have a monorepo with Yarn Workspaces, and sometimes, after having opened multiple files from different packages of my workspace, I get this error. It's quite frequent actually, and I'm starting to consider it a blocker. I permanently increased max file descriptors (both soft and hard limits) but still the server fails after some reloads. Let me know if you need more info, I could probably provide some logs. Also let me know of any workarounds, those would definitely be appreciated! |
|
Minimal repro. const fs = require('fs');
const path = require('path')
const {execSync} = require('child_process')
const lipzip = require('@yarnpkg/libzip')
const count = 4300;
const rootDir = path.resolve(__dirname, 'gen');
fs.rmSync(rootDir, { recursive: true, force: true });
fs.mkdirSync(rootDir);
for (let i = 0; i < count; i++) {
const p = path.join(rootDir, `file${i}.ts`);
fs.writeFileSync(p, 'content')
fs.openSync(p, 'r')
}
class Cls {
libzip = lipzip.getLibzipSync()
open(source) {
const errPtr = this.libzip.malloc(4);
try {
let flags = 0;
flags |= this.libzip.ZIP_RDONLY;
this.readOnly = true;
console.log('fd', fs.openSync(source, 'r'))
this.zip = this.libzip.open(source, flags, errPtr);
if (this.zip === 0) {
const error = this.libzip.struct.errorS();
this.libzip.error.initWithCode(error, this.libzip.getValue(errPtr, `i32`));
throw this.makeLibzipError(error);
}
} finally {
this.libzip.free(errPtr);
}
}
makeLibzipError(error) {
const errorCode = this.libzip.struct.errorCodeZip(error);
const strerror = this.libzip.error.strerror(error);
const libzipError = new Error(strerror+this.libzip.errors[errorCode]);
return libzipError;
}
}
setTimeout(() => {
const zip = new Cls()
zip.open('logs.txt.zip')
console.log('ended')
}, 1000)
console.log('pid', process.pid)
setTimeout(() => {
console.log('open descriptors: '+execSync(`lsof -p ${process.pid} | wc -l`, {encoding: 'utf8'}))
}, 3000)
setInterval(() => {
}, 1000);just run it with node |
|
So, seems like node has bigger(ulimited) fds limit, zipfs is not. It could be |
|
One of the solutions which could work, we can open file fd with node and open zip with zip_fdopen |
|
Wow. It's fixed in master 1431217#diff-523d93f5ae8070efae5918f815cd1be6ecd605cc6963491e8732dbe46bf316d7L161 |
|
it seems like |
|
Did you reproduce it since then? Marking the thread as auto-closable. |
arcanis
added
the
waiting for feedback
|
No, highly confident. |
Self-service
Describe the bug
So, with yarn pnp enabled, we updated from 4.8.4 to 5.0.4 and now we're getting
I've created a repro below, but I can't reproduce above error constantly. I got it once or twice, but reason could be other vscode open in parallel.
But what I can reproduce constantly, is that with 1k files (change it in gen.js) I have react-router resolved, but with 15k files it's not:
Error in this case is
{"name":"Libzip Error","code":"ZIP_ER_OPEN"}(you can log inmakeLibzipError, it's swallowed by ts server)If you disable pnp and change sdk to default you will have react-router resolved for both 1k and 15k.
What I found that in ts 4.9 they changed default watch method
microsoft/TypeScript#50366
From what I see in source code (in node-server), ts language service is using now fs events method
UPD. Incorrect. Because stacktrace has fs.watchFile, which is polling under the hood.
From what I see, for both pnp and not watchFile is creating FD for every file.
To reproduce
git clone https://github.com/goloveychuk/yarn-repro
yarn install
node gen.js
open project in vscode
select correct sdk
open index.ts
reload vscode window
Environment
System: OS: macOS 12.6 CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz Binaries: Node: 14.20.0 - /private/var/folders/_c/5f907xz5253bhss7ytr8m8zh0000gn/T/xfs-ac198389/node Yarn: 3.5.0 - /private/var/folders/_c/5f907xz5253bhss7ytr8m8zh0000gn/T/xfs-ac198389/yarn npm: 6.14.17 - /var/folders/_c/5f907xz5253bhss7ytr8m8zh0000gn/T/fnm_multishells/45914_1684763731174/bin/npmAdditional context
No response
The text was updated successfully, but these errors were encountered: