Repository navigation
Hang (possible deadlock) in PSScriptAnalyzer #1297
Description
Steps to reproduce
Warning: Do this in a new process that you know the PID of -- it will lock up.
iwr https://raw.githubusercontent.com/TravisEz13/PsAzDevOpsExt/master/src/PSPackageProject.psm1 -outfile ex.ps1
Invoke-ScriptAnalyzer -Path ex.ps1Expected behavior
PSSA emits any relevant diagnostics and returns
Actual behavior
Call never returns and does not respond to Ctrl+C
Environment data
> $PSVersionTable
Name Value ---- ----- PSVersion 7.0.0-preview.2
PSEdition Core
GitCommitId 7.0.0-preview.2
OS Darwin 18.7.0 Darwin Kernel Version 18.7.0: Thu Ju…
Platform Unix
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
> (Get-Module -ListAvailable PSScriptAnalyzer).Version | ForEach-Object { $_.ToString() }
1.18.1Debugging this, it seems to occur around this call. This behaviour is not present in 1.18.0.
Activity
rjmholt commentedon Jul 27, 2019
/cc James Truher (@JamesWTruher)
rjmholt commentedon Jul 27, 2019
The suspicion is that this is caused by the runspace pool deadlocking. The immediate solution is to rip that out, and down the line we should investigate implementing our own runspace pool.
bergmeister commentedon Jul 27, 2019
Possibly related: #1287
rjmholt commentedon Jul 27, 2019
The next step I think is to get a proper stack trace on Windows using a debugging environment that can drill into the platform code; it would be nice to prove that this is a deadlock
rjmholt commentedon Jul 30, 2019
Ok, after a bit more analysis I believe this is the same issue as Patrick Meinecke (@SeeminglyScience) describes in PowerShell/PowerShellEditorServices#762 (comment)
rjmholt commentedon Jul 30, 2019
Notice that the repro script contains a reference to
Install-Package, and a few other PackageManagement cmdletsrjmholt commentedon Jul 30, 2019
pssa.log
windbg thread stack dump
SeeminglyScience commentedon Jul 31, 2019
Looking at the windbg dump, I agree that definitely looks like the same issue. I'm not sure if there is anything on PSSA's end that can be done though.
I got side tracked before I could submit a PR to oneget, but I've been running with these changes for a few months now without any issues. Not sure when I'll get to submitting that PR if someone else wants to take that on. (Note that the fix itself could use some refinement, if possible avoiding
GetAwaiter().GetResult())rjmholt commentedon Jul 31, 2019
Unfortunately I think even if we get those changes into PackageManagement (which we should try to do), it will be hard to propagate them to users. Similarly, I think it's worth investigating if something can be done in PowerShell to prevent this, but it will only be possible to make such a change in PS 7.
So I think PSSA and PSES will need to special case the PackageManagement cmdlet parameters. Not ideal, but not all that hard. And they're not going to change, especially with PSGet 3.0 coming.
SeeminglyScience commentedon Jul 31, 2019
Ah right PSSA can do that, I forgot it's the one calling
CommandInfo.Parameters. I can't think of a way that PSES could though, it's being triggered throughTabExpansion2.