-
Notifications
You must be signed in to change notification settings - Fork 7.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Engine event processing bypasses "ShouldQueueAndProcessInExecutionThread" causing state corruption and crash due to Runspace affinity #4003
Comments
Repro no longer fails. |
@daxian-dbw did you reopen this as it's not fixed? if so, you should also remove the |
@SteveL-MSFT This is not fixed. |
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you. |
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes. |
This was found while investigating a PowerShell class static/instance method concurrency bug.
Background
When invoking a script block using
InvokeWithPipe
, if the script block is bound to a different Runspace (e.g. created in a different Runspace), then the script block will be marshaled to that Runspace using theEventManager
and is supposed to be executed by the main pipeline thread of that Runspace.This is how it's done:
InvokeWithPipe
finds that the script block is bound to another Runsapce and needs to run in that Runspace. (code here)EventManager
of the target Runspace, wishing the main pipeline thread of the target Runspace would pick up the event and run the script block. (code here)Issues
The problem is that, to avoid a possible hang, the thread, which waits for the main pipeline thread of the target Runspace, will pick up the event and execute it (not the required main pipeline thread) after waiting for 250 mSec (See the code here). This will result in 2 threads running in the same Runspace and changing its state simultaneously. This would cause:
Repro Steps
Deadlock
Both arguments for '-sb' and '-arg' are script blocks that are created in the powershell console session. So when
bar
runs$sb.InvokeReturnAsIs($arg)
in a new Runspace, it needs to marshal it back to the powershell console session. This is what happens:$ps.Invoke()
;$arg
and goes back to step (1). However, this time when it comes to step (3), an event is already executing. Sothis.ProcessPendingActions()
will immediately return, and the requesting thread will be stuck in the while loop.Runspace state corruption and process crash
This repro creates a script
DoInvokeInParallel.ps1
that dot-sources anInvoker.ps1
file which defines a class with a static method. RunDoInvokeInParallel.ps1
in multipleRunspaces
via aRunspacePool
to use the class static method concurrently.Invoker.ps1
fileDoInvokeInParallel.ps1
fileRun
DoInvokeInParallel.ps1
. The result is multiple "invalid session state" asserts if you are using a debug flavor Windows PowerShell. Eventually, the process will crash.The text was updated successfully, but these errors were encountered: