Cannot read properties of undefined (reading 'close')

[mjbvz]

Bug Report

🔎 Search Terms

• watcher
• crash

🕗 Version & Regression Information

4.8.0-dev.20220711

Seems like a regression as I do not remember seeing this in TS 4.7

Details

When closing editors in VS Code, recently I've been seeing the following crash:

  ERR <semantic> TypeScript Server Error (4.8.0-dev.20220711)
Cannot read properties of undefined (reading 'close')
TypeError: Cannot read properties of undefined (reading 'close')
    at Object.close (/Users/matb/projects/vscode/node_modules/typescript/lib/tsserver.js:6834:29)
    at Object.close (/Users/matb/projects/vscode/node_modules/typescript/lib/tsserver.js:116840:29)
    at closeFileWatcherOf (/Users/matb/projects/vscode/node_modules/typescript/lib/tsserver.js:116891:32)
    at Map.forEach (<anonymous>)
    at Object.clearMap (/Users/matb/projects/vscode/node_modules/typescript/lib/tsserver.js:19668:13)
    at Object.clear (/Users/matb/projects/vscode/node_modules/typescript/lib/tsserver.js:122531:16)
    at ConfiguredProject.Project.close (/Users/matb/projects/vscode/node_modules/typescript/lib/tsserver.js:171446:38)
    at ConfiguredProject.close (/Users/matb/projects/vscode/node_modules/typescript/lib/tsserver.js:172930:40)
    at ProjectService.removeProject (/Users/matb/projects/vscode/node_modules/typescript/lib/tsserver.js:173991:25)
    at /Users/matb/projects/vscode/node_modules/typescript/lib/tsserver.js:175861:86
    at Map.forEach (<anonymous>)
    at ProjectService.removeOrphanConfiguredProjects (/Users/matb/projects/vscode/node_modules/typescript/lib/tsserver.js:175861:44)
    at ProjectService.cleanupAfterOpeningFile (/Users/matb/projects/vscode/node_modules/typescript/lib/tsserver.js:175805:22)
    at ProjectService.applyChangesInOpenFiles (/Users/matb/projects/vscode/node_modules/typescript/lib/tsserver.js:176009:26)
    at Session.handlers.ts.Map.ts.getEntries._a.<computed> (/Users/matb/projects/vscode/node_modules/typescript/lib/tsserver.js:177372:46)
    at /Users/matb/projects/vscode/node_modules/typescript/lib/tsserver.js:179564:96
    at IpcIOSession.Session.executeWithRequestId (/Users/matb/projects/vscode/node_modules/typescript/lib/tsserver.js:179555:28)
    at IpcIOSession.Session.executeCommand (/Users/matb/projects/vscode/node_modules/typescript/lib/tsserver.js:179564:41)
    at IpcIOSession.Session.onMessage (/Users/matb/projects/vscode/node_modules/typescript/lib/tsserver.js:179592:35)
    at process.<anonymous> (/Users/matb/projects/vscode/node_modules/typescript/lib/tsserver.js:183758:31)
    at process.emit (node:events:390:28)
    at emit (node:internal/child_process:917:12)
    at processTicksAndRejections (node:internal/process/task_queues:84:21): Error: <semantic> TypeScript Server Error (4.8.0-dev.20220711)

I can't repo this reliably but here's the complete log of a session the crashed (it's quite large)
tsserver.log.zip

[DanielRosenwasser]

First error in logs is possibly #49310

[jakebailey]

Based on the trace (closeFileWatcherOf followed by two close calls), I think this is caused by a double-close of this watcher:

TypeScript/src/compiler/sys.ts

Line 1098 in 7b76416

watcher = undefined!;

It's not clear to me from the API of FileWatcher whether or not a double close is intended to be to be legal (I'll add some asserts to various implementations to check), but I think making this one not crash is straightforward.

[jakebailey]

I can't say I know for sure if the API should allow double closes or not; there are clearly some refcounted file watchers which just start returning early once their references are up. There are also some other cases (different from this issue's trace) which could potentially crash if some invariant were violated, but we a aren't seeing those. So I'm inclined to go the safer route that doesn't do a undefined!.