1

We use Github Actions to build and test our ActiveX control. We started a few weeks ago and made a lot of progress. We build and test for x86 and x64 using a matrix. Starting a week ago the two build still succeed and the x64 unit test succeeded but the x86 unit test fails.
Sometimes after 5 min. sometime after 50 min. we get errors like these:

The active test run was aborted. Reason: Test host process crashed : Fatal error. Internal CLR error. (0x80131506)
Test Run Aborted with error System.AggregateException: One or more errors occurred. 
  ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. 
    ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
Test Run Aborted with error System.AggregateException: One or more errors occurred. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
Total tests: Unknown
   --- End of inner exception stack trace ---
     Passed: 31
   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
    Skipped: 1
   at System.IO.Stream.ReadByte()
   at System.IO.BinaryReader.ReadByte()
   at System.IO.BinaryReader.Read7BitEncodedInt()
   at System.IO.BinaryReader.ReadString()
   at Microsoft.VisualStudio.TestPlatform.CommunicationUtilities.LengthPrefixCommunicationChannel.NotifyDataAvailable()
   at Microsoft.VisualStudio.TestPlatform.CommunicationUtilities.TcpClientExtensions.MessageLoopAsync(TcpClient client, ICommunicationChannel channel, Action`1 errorHandler, CancellationToken cancellationToken)

The active test is randomly different, making me believe the problem is not with the test.

The unit tests are the same for x86 and x64, we don't have specific tests.
Both builds are fine and run around 8-10 min. Also, the produced artifacts look fine.

The Actions results can be viewed at our public repo at https://github.com/MapWindow/MapWinGIS/actions

This is our Actions script for the test part:

    # Build test solution
    - name: setup-msbuild
      uses: microsoft/setup-msbuild@v1.1    
      with:
        msbuild-architecture: x64
        
    - name: Build test solution ${{matrix.platform}}
      working-directory: ${{env.GITHUB_WORKSPACE}}
      run: msbuild /m:2 /p:Configuration=${{env.BUILD_CONFIGURATION}} /p:Platform=${{matrix.platform}} -restore /v:m ${{env.UNITTESTS_SOLUTION_FILE_PATH}}      
      
    # Run unit tests
    - name: Setup VSTest.console.exe
      uses: darenm/Setup-VSTest@v1 
 
    - name: Unit Testing x86
      if: ${{matrix.platform == 'Win32' }}
      run: vstest.console.exe /Parallel /Blame /Diag:logs\log.txt /Platform:x86 -e:PROJ_LIB="${{ github.workspace }}\src\bin\Release\Win32\proj7\share\" .\unittest-net6\UnitTests\bin\x86\${{env.BUILD_CONFIGURATION}}\net6.0-windows8.0\unittest-net6.dll
    - name: Unit Testing x64
      if: ${{matrix.platform == 'x64' }}
      run: vstest.console.exe /Parallel /Blame /Diag:logs\log.txt /Platform:x64 -e:PROJ_LIB="${{ github.workspace }}\src\bin\Release\x64\proj7\share\" .\unittest-net6\UnitTests\bin\x64\${{env.BUILD_CONFIGURATION}}\net6.0-windows8.0\unittest-net6.dll

Edit:
Removing the /Parallel argument for vstest.console.exe did result in 1 successful run. The next run, however, failed again with the same error. I build and run my unit tests on windows-2022 with dotnet-version: '6.x'. The windows-2022 image uses VS2022

Paul Meems
  • 3,002
  • 4
  • 35
  • 66
  • If I had to guess it would be a threading issue ... – jessehouwing Mar 02 '22 at 09:24
  • @jessehouwing: You are right. I just found another post somewhere suggesting the `/Parallel` is causing the problem. I removed it and now my unit tests are successful again. If you post this as an answer I will accept yours. – Paul Meems Mar 02 '22 at 09:44
  • I cheered too soon. I ran the Action again and now I have the `Unable to read data from the transport connection` exception again. – Paul Meems Mar 02 '22 at 10:25
  • Urgh... But can still be a threading issue in the activex control where it locks up the message pump... – jessehouwing Mar 02 '22 at 16:12
  • If it is a threading issue, what can I do to fix it? – Paul Meems Mar 03 '22 at 09:07
  • Probably somewhere in your ActiveX control or the code that tests it... You could take a process dump of the test runner when it's slow but that requires your ability to repro the issue out of the hosted agent. – jessehouwing Mar 03 '22 at 09:22
  • Did you ever resolve this @jessehouwing? – DTynewydd Nov 25 '22 at 11:23

0 Answers0