Activity

1. kilasuit commented on Jul 26, 2023

   

   Ryan Yates (kilasuit)

   on Jul 26, 2023

   Last edited by kilasuit

   More actions

   I cannot repro this in 5.1 or 7.3.6 when running in or out of WT, either when using Microsoft.PowerShell.ThreadJob v2.1.0 or ThreadJob 2.0.3 on Microsoft Windows 10.0.25905 - aka Win 11 23H2 via the Insiders Dev ring
2. kborowinski commented on Jul 27, 2023

   

   Kris Borowinski (kborowinski)

   on Jul 27, 2023

   Author

   More actions

   Where can I get the 2.1.0 version, so I could test it on Windows 10 and PowerShell 5.1 and 7.3.6? On PowerShell Gallery there is only 2.0.3. The same on GitHub repo.
3. kilasuit commented on Jul 27, 2023

   

   Ryan Yates (kilasuit)

   on Jul 27, 2023

   Last edited by kilasuit

   More actions

   Install-Module Microsoft.PowerShell.ThreadJob installs the renamed and updated ThreadJob module & ThreadJob module is technically obsolete going forward as when the PowerShell team took ownership of the module it was renamed, although I think this may not have been well communicated at the time

   👍React with 👍1Reacted by Kris Borowinski
4. kborowinski commented on Jul 27, 2023

   

   Kris Borowinski (kborowinski)

   on Jul 27, 2023

   Author

   More actions

   Thanks, sorry, I've missed the info about the new module name. Will test it tomorrow. I've just finished a 9 hour car drive for the holidays so I wasn't thinking clearly.
5. kborowinski commented on Jul 27, 2023

   

   Kris Borowinski (kborowinski)

   on Jul 27, 2023

   Last edited by kborowinski

   Author

   More actions

   Ryan Yates (@kilasuit) Did test it with Microsoft.PowerShell.ThreadJob module v2.1.0, still the same issue:
   

   To be sure, I have tested it on 3 different computers:

   1. Windows Server 2019,
   2. Windows 10 Home,
   3. Windows 10 Pro

   Also always try it on the new PowerShell session, do not try it in the current if there was no repro. If still no success try this example:

   $cpuCount = [Environment]::ProcessorCount
   
   $splatStartThreadJob = @{
       ThrottleLimit = $cpuCount
       StreamingHost = $Host
       ErrorAction = 'Stop'
       InitializationScript = {Import-Module Pester -Force -ErrorAction Stop}
   }
   
   $threadJobs = 1..($cpuCount * 2) | ForEach-Object {
       Microsoft.PowerShell.ThreadJob\Start-ThreadJob -Name $_ -ScriptBlock {
           $pc = New-PesterConfiguration
           $pc.Run.Container = New-PesterContainer -ScriptBlock {Describe 'd' { It 'i' { 1 | Should -Be 1 }}}
           $pc.Output.Verbosity = 'None'
           $pc.Run.PassThru = $true
           $pc.Run.SkipRemainingOnFailure ='Block'
           [PSCustomObject]@{
               Test    = $Using:_
               Result  = Invoke-Pester -Configuration $pc
           }
       } @splatStartThreadJob
   }
   
   Wait-Job -Job $threadJobs | Receive-Job

   
6. kilasuit commented on Jul 28, 2023

   

   Ryan Yates (kilasuit)

   on Jul 28, 2023

   More actions

   Adding this snippet from the Discord discussion yesterday from Patrick Meinecke (@SeeminglyScience) as another way to repro this

   $event = [System.Threading.ManualResetEvent]::new($false)
   $jobs = 1..500 | % {
       Start-ThreadJob {
           $event = $using:event
           $null = $event.WaitOne()
           $supportsVT = $Host.UI.psobject.Properties['SupportsVirtualTerminal'].Value
       } -StreamingHost $Host
   }
   
   Start-Sleep -Milliseconds 500
   $null = $event.Set()
   
   $jobs | Receive-Job -AutoRemoveJob -Wait

   👍React with 👍1Reacted by Kris Borowinski
7. SteveL-MSFT commented on Aug 23, 2023

   

   Steve Lee (SteveL-MSFT)

   on Aug 23, 2023

   Member

   More actions

   Based on the callstack, it appears that ListDictionary is being used somewhere which is not threadsafe. In this case, this doesn't appear to be an issue with ThreadJob itself, but something the thread is accessing is not threadsafe and results in the race condition.

   If the actual use case is to see within a thread if SupportsVirtualTerminal is true/false, then it would be best to capture that outside of the thread job and pass it in.

   👍React with 👍1Reacted by Kris Borowinski
8. kborowinski commented on Aug 23, 2023

   

   Kris Borowinski (kborowinski)

   on Aug 23, 2023

   Author

   More actions

   The issue was detected first when the Pester was executed with ThreadJob in order to speed up infrastructure tests. Pester is accessing the SupportsVirtualTerminal inside the Pester.psm1. I guess that Pester authors weren't aware that this is not thread safe and it would require change in Pester code.

   I got lots of help from Patrick Meinecke (@SeeminglyScience), when debugging this issue. Maybe you could contact him for some more in-depth analysis.
9. SeeminglyScience commented on Aug 23, 2023

   

   Patrick Meinecke (SeeminglyScience)

   on Aug 23, 2023

   Last edited by SeeminglyScience

   More actions

   I would agree that I don't think it's a ThreadJob problem. My guess is that it's a race condition in how PowerShell is creating the internal PSMemberInfoCollection<> and caching it in the member resurrection table.

   At a glance it looks like there's a lock around the creation of the underlying collection, but the collection itself is populated lazily with no lock.

   I'd also second the suggestion of working around it by accessing the object before hand in the primary thread if possible. I'm hesitant to suggest more locks there as it may have a noticeable impact on performance for an issue that doesn't get hit often.

   👍React with 👍1Reacted by Kris Borowinski