$PSVersionTable (on macOS):Name Value
---- -----
PSVersion 6.0.0-beta
PSEdition Core
GitCommitId v6.0.0-beta.6
OS Darwin 16.7.0 Darwin Kernel Version 16.7.0: Thu Jun 15 17:36:27 PDT 2017; root:xnu-3789.70.16~2/RELEASE_X86_64
Platform Unix
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
From macOS:
PS> code -v
1.15.1
41abd21afdf7424c89319ee7cb0445cc6f376959
PS> $pseditor.EditorServicesVersion
Major Minor Build Revision
----- ----- ----- --------
1 4 1 0
PS> code --list-extensions --show-versions
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
PS> $PSVersionTable
Things start to go wrong when the PS version cannot be determined and the version is assumed to be v5:
[WARNING] - Method "GetVersionDetails" at line 153 of C:\projects\powershelleditorservices\src\PowerShellEditorServices\Session\PowerShellVersionDetails.cs
Failed to look up PowerShell version, defaulting to version 5.
In effect, the Editor Services don't work properly on either platform, but some aspects still work on Linux, such as F8.
On macOS, the logs show additional failures:
System.AggregateException: One or more errors occurred. (Too many open files) ---> System.IO.IOException: Too many open files
...
PowerShell Editor Services is terminating due to an unhandled exception
Note that ulimit -n (number of files that can be open simultaneously) still defaults to 256 as of macOS 10.12.6.
Hey Michael, are you opening a workspace that contains a lot of files? I've seen this issue reported in such cases because we're scanning the workspace files to find symbol details for reference and definition searches. Seems we might be leaking file handles, so I'll need to look into that.
Thanks, @daviwil.
Looks like you've identified the problem on macOS: The problem only happens in a large directory subtree with 12336 files, although only 36 of the files are PS-related (*.ps1 / *.psd1 / *.psm1).
Seemingly, all 12336 files are scanned and kept open, because even raising ulimit -n to the macOS 10.12 maximum of 10240 doesn't help.
Note that the default ulimit -n value is:
On Ubuntu I no longer see any problems after upgrading to 1.16 / 1.4.3
Thanks for the additional details! I'll see if I can figure out a better way to open those files to work around the handle leakage, might be able to ship an update in the next couple of days.
Hi @daviwil, just wondering if you were able to look into this at all? I'm getting the same 'Too many open files in system' issue and lsof shows a huge number of files open under powershell processes.
I'm using VS Code 1.19.2, vscode-powershell 1.5.1 and MacOS 10.12.6.
Adding a note here that this issue is also impacting my setup. Hoping for some resolution when possible.
This is probably due to the reference resolver looking for definitions. @SeeminglyScience made a couple of great improvements in the references code to improve here. @glennsarti also added new file exclusion configurations coming in the next release that will help with that. Beyond that we might need to look into this further and find out if there's anything else we can do to limit file usage while still getting references.
Most helpful comment
Hi @daviwil, just wondering if you were able to look into this at all? I'm getting the same 'Too many open files in system' issue and
lsofshows a huge number of files open under powershell processes.I'm using VS Code 1.19.2, vscode-powershell 1.5.1 and MacOS 10.12.6.