New unexpected build failures on 20240603.1.0

Description
Our PR builds had been working fine as expected until last night when the runners updated to the 20240603.1.0 image. An impacted PR is here:
https://github.com/microsoft/DirectXShaderCompiler/pull/6668
Earlier iterations of the PR build successfully, but the builds began failing once the image updated.
See a failing build here:
https://dev.azure.com/DirectXShaderCompiler/public/_build/results?buildId=6383&view=results
And a previously successful one here:
https://dev.azure.com/DirectXShaderCompiler/public/_build/results?buildId=6371&view=results
Platforms affected

[X] Azure DevOps
[ ] GitHub Actions - Standard Runners
[ ] GitHub Actions - Larger Runners

Runner images affected

[ ] Ubuntu 20.04
[ ] Ubuntu 22.04
[ ] Ubuntu 24.04
[ ] macOS 11
[ ] macOS 12
[ ] macOS 13
[ ] macOS 13 Arm64
[ ] macOS 14
[ ] macOS 14 Arm64
[ ] Windows Server 2019
[X] Windows Server 2022

Image version and build link
Image: 20240603.1.0
https://dev.azure.com/DirectXShaderCompiler/public/_build/results?buildId=6383&view=results
Is it regression?
20240514.3.0
Expected behavior
Our builds should work?
https://dev.azure.com/DirectXShaderCompiler/public/_build/results?buildId=6371&view=results
Actual behavior
The build fails with errors we don't encounter locally or on older VM images.
Repro steps
We cannot reproduce outside the VM image.

We are also seeing new issues in the 20240603.1.0 Windows Server 2022 image.
Specifically, in our case, a built executable yields an access violation when attempts are made to run it as part of later stages of our build process.

We're also seeing issues with windows-2022 runners starting sometime in the last two days; re-running previously successful jobs consistently result in failures.
In our case, the builds themselves succeed but trying to run any of the resulting executables fails with Access violation.

We're also seeing similar issues on windows-2022 with

success on old runner version (20240514.3.0): https://github.com/iree-org/iree/actions/runs/9401944863/job/25894862559
failure on new runner version (20240603.1.0): https://github.com/iree-org/iree/actions/runs/9404522541/job/25903631922

Errors are all segfaults trying to run executable files.

The issue may be due to a combination of the ordering of the PATH environment variable, older versions of vcruntime bundled with Python, and changes in VS 2022 17.10 STL that require the latest vcruntime.
When running the following on windows-2022:20240603.1.0 I see:
echo ((Get-Command vcruntime140.dll).Path) = C:\hostedtoolcache\windows\Python\3.9.13\x64\vcruntime140.dll
echo ((Get-Command vcruntime140.dll).Version) = 14.29.30139.0
But the system-installed version (at C:\Windows\system32\vcruntime140.dll) is 14.40.33810.00
As noted in the VS 2022 17.10 STL release notes:

Fixed mutex's constructor to be constexpr. https://github.com/microsoft/STL/pull/3824 >   - https://github.com/microsoft/STL/pull/4000 https://github.com/microsoft/STL/pull/4339

Note: Programs that aren't following the documented restrictions on binary compatibility may encounter null dereferences in mutex machinery. You must follow this rule:

When you mix binaries built by different supported versions of the toolset, the Redistributable version must be at least as new as the latest toolset used by any app component.

Reference: https://github.com/microsoft/STL/releases/tag/vs-2022-17.10
Another reference: https://developercommunity.visualstudio.com/t/Access-violation-in-_Thrd_yield-after-up/10664660?sort=active
And, in fact, I can confirm that built executables run correctly on a VM where I've ensured that vcruntime140.dll version 14.40.33810.00 is what's loaded.

Possible recommendations for windows images:

Given https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=msvc-170, it might make sense to remove any local / applocal copies of the VCruntime files in installed tool paths that end up in the PATH environment variable (at least, in the ones that show up before C:\Windows\system32). And/or reorder the PATH environment variable.

Also seeing segfaults running executables from a windows-latest (20240603.1.0) runner. Was fine on 20240514.3.0.
Private repo so can't share runs, but it looks very similar to the other reports. In our case we're running pluginval.exe against some audio plugins built by the runner. Interestingly not an immediate segfault. Runs through several test phases before failing.
Starting tests in: pluginval / Editor...
D:\a\_temp\7e7e13d1-ac8c-4be7-bda4-e292e2e5bb48.sh: line 3:  1317 Segmentation fault      ./pluginval.exe --strictness-level 10 --verbose --validate "build/plugin/[REDACTED].vst3"
##[error]Process completed with exit code 139.```

DLL confusion due to PATH issues makes a lot of sense - I had a build succeed just now simply by changing the workflow to build in Debug rather than Release. The executables would then be looking for d-suffixed DLLs in the PATH, which wouldn't conflict.

I also see a regression on the GDAL (https://github.com/OSGeo/gdal) CI related to that change, causing crashes during tests execution:

Last good build: https://github.com/OSGeo/gdal/actions/runs/9392254916/job/25869181603?pr=10145 (Version: 20240514.3.0)
Failed build: https://github.com/OSGeo/gdal/actions/runs/9404419267/job/25903290692?pr=10149 (Version: 20240603.1.0)

We hit this too and traced it back to mutex usage.  This looks like https://developercommunity.visualstudio.com/t/Access-violation-in-_Thrd_yield-after-up/10664660#T-N10668856, which suggests an older incompatible version of msvcp140.dll is being used in this image.

20240603.1.0 broke us too; it looks like a similar mysterious executable error as other folks are mentioning:

Failing: https://github.com/buildbuddy-io/buildbuddy/actions/runs/9406760840/job/25910946394
Good: https://github.com/buildbuddy-io/buildbuddy/actions/runs/9402894773/job/25898065564

Given https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=msvc-170, it might make sense to remove any local / applocal copies of the VCruntime files in installed tool paths that end up in the PATH environment variable (at least, in the ones that show up before C:\Windows\system32). And/or reorder the PATH environment variable.

I've attempted that in https://github.com/rouault/gdal/actions/runs/9407632196/job/25913839874, copying c:\Windows\system32\vcruntime140.dll in a specific directory and putting it in front of the path, but it appears that the version of c:\Windows\system32\ is only 14.32.31326 , and not >= 14.40.33810.00. I would argue that the runner-image should be fixed to have a recent enough vcruntime140.dll in front of the PATH.
A workaround I found when reading https://developercommunity.visualstudio.com/t/Access-violation-in-_Thrd_yield-after-up/10664660#T-N10668856 is that you can define "/D_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR" when building your software to revert to a std::mutex constructor compatible of older vcruntimes : https://github.com/rouault/gdal/commit/c4ab31f0eb1c196dff2d561292a29d8840223790 . My builds work fine with that workaround.

Can we expect a rollback or some other fix to the runner images, or will affected projects need to use one of the listed workarounds? Is there a way to use older/stable runner images instead of this new version?

Seeing this also
Runner image 20240514.3.0 works fine
https://github.com/randombit/botan/actions/runs/9408188903/job/25918967600
Runner image 20240603.1.0, built binaries fail with error code<PHONE_NUMBER>
https://github.com/randombit/botan/actions/runs/9408188903/job/25918967856
Same code in this case; one (working) is the PR the second (failing) is the merge of that PR into master.

Getting similar errors today with the new images, simply executing curl to download a binary. affecting windows-2019 and windows-2022 images. ( I was using windows-latest, but tried windows-2019, same result)
🔵  Downloading ffi v0.4.24 for pact_ffi-windows-x86_64.dll.gz
Error: Process completed with exit code 43.

Here is a re-run of job today, using a newer runner, that passed yesterday.
🟢 20240514.3.0 - https://github.com/YOU54F/pact-js-core/actions/runs/9392917514/job/25868610705#step:1:9
🔴 20240603.1.0 - https://github.com/YOU54F/pact-js-core/actions/runs/9392917514/job/25920895001#step:1:9

@llvm-beanz - Kindly re-run the pipeline now. And also if you face same error again, please share the yaml script/snippet for Building task from the pipeline.

I also see failed pipelines in new build [20240603.1.0]. Errors in solution restore task:
C:\Program Files\dotnet\sdk\8.0.300\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(154,5):  error NETSDK1145: The Apphost pack is not installed and NuGet package restore is not supported.  Upgrade Visual Studio, remove global.json if it specifies a certain SDK version, and uninstall the newer SDK.  For more options visit   https://aka.ms/targeting-apphost-pack-missing  Pack Type:Apphost, Pack directory:  C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Host.win-x86, targetframework: net7.0, Pack PackageId:  Microsoft.NETCore.App.Host.win-x86, Pack Package Version: 7.0.19 [D:\***.vcxproj]
Is it related to some issues on host machine or some changes should be done on our end? Projects use .NET 7, but host machine seems uses .NET SDK 8.

I also see failed pipelines in new build [20240603.1.0]. Errors in solution restore task: C:\Program Files\dotnet\sdk\8.0.300\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(154,5): error NETSDK1145: The Apphost pack is not installed and NuGet package restore is not supported. Upgrade Visual Studio, remove global.json if it specifies a certain SDK version, and uninstall the newer SDK. For more options visit https://aka.ms/targeting-apphost-pack-missing Pack Type:Apphost, Pack directory: C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Host.win-x86, targetframework: net7.0, Pack PackageId: Microsoft.NETCore.App.Host.win-x86, Pack Package Version: 7.0.19 [D:\***.vcxproj]  Is it related to some issues on host machine or some changes should be done on our end? Projects use .NET 7, but host machine seems uses .NET SDK 8.

@kubo990 ,  It would be helpful if you share the vsbuild stage yaml script . also confirm in which SDK your application developed.

This has broken all Windows-based Azure pipelines in our Company and everyone is halted. I wonder how much would it cost for us...

I think windows-next would be a good idea in the future... Just roll it back guys!

@kubo990 , It would be helpful if you share the vsbuild stage yaml script . also confirm in which SDK your application developed.

@kishorekumar-anchala Application targets .NET 7 SDK. Workaround was adding UseDotNet task with specifing/installing sdk 7.0, however I don't think that it should be needed, according to doc, SDK 7.0 should be still installed on windows-2022 agent.
- task: UseDotNet@2
  displayName: 'Use .NET Core sdk 7.x'
  inputs:
    version: 7.x

there are no special commands in yaml pipeline. it fails on nuget restore task.
name: $(Build.BuildId)

pool:
  vmImage: 'windows-2022'

trigger:
  - 'develop'

pr:
  - 'develop'

steps:
***(some powershell not related tasks)

- task: NuGetCommand@2
  displayName: 'Restore NuGet Packages'
  inputs:
    restoreSolution: 'SolutionName.sln'

*** build tasks

`

There's a copy of vcruntime140.dll version 14.40.33810 in C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Redist\MSVC\14.40.33807\x64\Microsoft.VC143.CRT.
Adding this to GITHUB_PATH doesn't seem to help in my case, my tests are still failing with unknown file: error: SEH exception with code 0xc0000005 thrown in the test body., but perhaps this might be useful to someone else.

Is there a workaround other than doing debug builds? This is heavily impacting pipelines of many of our projects and we definitely need Windows doing builds and packages on CI

Also affected over at https://github.com/f3d-app/f3d/

OK, copying all DLLs from C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Redist\MSVC\14.40.33807\x64\Microsoft.VC143.CRT to the same directory as the test binaries fixed the issue for me.
I added the following stage between building and testing, bin\Release is where all the test binaries live.
Copy-Item (Join-Path `     ((Get-ChildItem -Directory `         -Path "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Redist\MSVC\14.*" |       Sort -Descending | Select-Object -First 1).FullName     ) 'x64\Microsoft.VC143.CRT\*.dll') "bin\Release"

Aside from needing to fix the image, I guess this also means there should be a smoke test for any new image roll out.

@llvm-beanz - Kindly re-run the pipeline now. And also if you face same error again, please share the yaml script/snippet for Building task from the pipeline.

I was the original reporter to @llvm-beanz
A colleague ran a similar pipeline starting about 20 minutes ago, for https://github.com/microsoft/DirectXShaderCompiler/pull/6679
The Azure pipepline for a VS2022 release build is: https://github.com/microsoft/DirectXShaderCompiler/pull/6679/checks?check_run_id=25949596545
It failed after 6 minutes, with raw log https://dev.azure.com/DirectXShaderCompiler/5060fecd-942c-4880-bb20-b8b29e0cbfe1/_apis/build/builds/6389/logs/50
I believe  Azure pipeline is defined in https://github.com/microsoft/DirectXShaderCompiler/blob/main/azure-pipelines.yml

Looks like it affects another project.
This PR: https://github.com/KhronosGroup/SPIRV-LLVM-Translator/pull/2598
This job: https://github.com/KhronosGroup/SPIRV-LLVM-Translator/actions/runs/9419555155/job/25949562007?pr=2598
This workflow: https://github.com/KhronosGroup/SPIRV-LLVM-Translator/blob/7d6d66975ff394a18e60db2e83aa872b65180248/.github/workflows/check-in-tree-build.yml#L110
It's doing a release build with VS2022, and the symptom is:
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(254,5): error MSB8066: Custom build for 'D:\a\SPIRV-LLVM-Translator\SPIRV-LLVM-Translator\build\CMakeFiles\8bc6b7dc048b6551197d3c360a7ac54d\ARMTargetParserDef.inc.rule;D:\a\SPIRV-LLVM-Translator\SPIRV-LLVM-Translator\build\CMakeFiles\edf72b9a29a2179a19058e3c565d1071\ARMTargetParserTableGen.rule;D:\a\SPIRV-LLVM-Translator\SPIRV-LLVM-Translator\llvm-project\llvm\include\llvm\TargetParser\CMakeLists.txt' exited with code -1073741819. [D:\a\SPIRV-LLVM-Translator\SPIRV-LLVM-Translator\build\include\llvm\TargetParser\ARMTargetParserTableGen.vcxproj]

Basically, error MSB8066: Custom build  ... exited with code -1073741819.   I've seen that exit code across many affected jobs.

Same things, had to update our LLVM toolchain to 17.0+ because of updated SDK headers, now every application built with that toolchain fails to run with a segfault:
https://github.com/fragcolor-xyz/shards/actions/runs/9416413387/job/25940571766
I downloaded the built binary and ran the application on my owned system and it ran without problems.
Seems indeed like a runtime dll issue.

I was able to run it in with MSVC ASAN enabled: https://github.com/mmomtchev/magickwand.js/actions/runs/9422296093/job/25958255145
The faulty DLL is C:\Windows\SYSTEM32\MSVCP140.dll
I don't have the problem with debug builds.

I'm seeing this issue across many repositories. Can confirm that passing this to cmake is a functioning workaround: -DCMAKE_CXX_FLAGS=" /D_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR"

I've had this issue as well. If rolling back is an option, here's how I did it:
Install the last version of VS build tools 17.9 with this block in your YAML:
- name: Install VS2022 BuildTools 17.9.7
  run: choco install -y visualstudio2022buildtools --version=<IP_ADDRESS> --params "--add Microsoft.VisualStudio.Component.VC.Tools.x86.x64 --installChannelUri https://aka.ms/vs/17/release/180911598_-255012421/channel"
  if: runner.os == 'Windows'

The --installChannelUri param is used due to this issue: https://github.com/jberezanski/ChocolateyPackages/issues/100
When building, activate the VS dev shell in the same run step (I'm not sure how to persist the dev shell activation across run steps. Copying the PATH didn't seem to help)
# --- Spawn the VS shell
if ($IsWindows) {
  Import-Module 'C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\Common7\Tools\Microsoft.VisualStudio.DevShell.dll'
  Enter-VsDevShell -VsInstallPath 'C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools' -DevCmdArguments '-arch=x64 -host_arch=x64'

  # Used for python building
  $env:DISTUTILS_USE_SDK=1
}

A full example is located on my ExllamaV2 fork which had problems building on VS build tools v17.10.

Our builds are affected too with many in-flight PR's stalled. In our case the exceptions are all 0xC0000005 which occurs when there is a problem loading a dependent DLL which chimes with the DLL version issues described earlier.
Needs an urgent fix. Please scrap this update, roll back to 20240514.3.0 wait until you have a proper fix before updating again.

Also having the same issue
adding this line fixed it for my project
target_compile_definitions(${target_name} _DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR)
https://github.com/odygrd/quill/commit/9cd69094c513e536b5ad1e7a0fbc92174a1a9cf7

@ijunaidm, the traffic on this issue suggests this is a widespread problem. Can you please roll back the image to the older version while you sort this out so that further disruption can be avoided?
Faulty CI for an extended period of time results in huge and expensive productivity disruptions.

@ashtom we’re two days into a significant outage caused by an image update to the GitHub Actions and Azure Pipelines Windows Images.

Well, I also ran into the mutex problem with release builds. From a crash dump of my executable I can clearly see that it is using the VS 17.10 STL headers (_MSVC_STL_UPDATE==202402) and that _DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR is not defined. As a result, the constexpr constructor of std::mutex is called, which initializes _Mtx_storage._Critical_section with zeros. The non-constexpr constructor would call _Mtx_init_in_situ() which is not just zero-initializing things. The gotcha: When e.g. std::mutex::lock() is called, the code lives in the msvcp140.dll. In the crash dump I can clearly see that it is using "C:\Windows\System32\msvcp140.dll" which is at version 14.32.313260.0. This corresponds to the STL shipped with VS 17.2. And that dll basically assumes that the mutex internals are "properly" initialized with _Mtx_init_in_situ(). But they aren't.
As mentioned @past-due here, VS 17.10 STL breaks the ABI compatiblity (specifically in https://github.com/microsoft/STL/pull/4339).

GitHub staff, please conduct a post-mortem into how this breakage happened and take steps, e.g. improved testing, to ensure such breakages do not happen again.

GitHub staff, please conduct a post-mortem into how this breakage happened and take steps, e.g. improved testing, to ensure such breakages do not happen again.

Although I agree that the Github team should probably compile some non-trivial software with their runner images before deploying, the underlying issue is the Microsoft one. DLLs are versioned so that this does not happen. This can happen to your users too - if they don't have the correct DLL, they will have a crash.
This means that the only to ensure that those binaries work is to include this runtime in the package. I might as well link it statically in this case, why I use a shared library at all. Microsoft, what have you done.

+1 as many, previously reported as #10020, before I was redirected to this one.
The justifications from Microsoft about the proposed workaround are really pathetic. They created a huge mess on the build + test + deployment and when many users complain about a crash, they close it as "by design". By design !!! And they propose no reliable way to always select the "right" VC redistributable so that it works.
Sorry about that, GitHub team, it is probably not your fault. But all users need a reliable CI pipeline for C++ applications to build and test. And, as of today, it is simply broken. Fully broken.
I am not the only one to ask for this here: Please revert to the previous runner image until you find a way to build a reliable runner image for C++ applications with the new versions.

@Sedeniono

Can't the Windows runner simply also have the latest redistributable installed? That should fix the issue.

I thought it would, but it seems more complicated than that.
In the workflow, before building the C++ app, I search the "VC redistributable package" which comes with the VS I use for the build and installed it before building. So the scenario of the workflow is

Locate MSBuild.exe and vc_redist.x64.exe from the current VS install. In that case, they are both found under C:\Program Files\Microsoft Visual Studio\2022\Community
Install vc_redist.x64.exe
Build the C++ application using MSBuild.exe
Run the application => still fails the same way

See a demonstrator here: https://github.com/lelegard/gh-runner-lock-2
So, the problem is worse than that. Even if you install the same VC runtime as used for the compilation, it does not work either.

Currently, inside a GH runner, the list of Path elements with MSVC DLL's and their version information is:
C:\Program Files\PowerShell\7
    C:\Program Files\PowerShell\7\vcruntime140_cor3.dll => 14.38.33130.0
C:\Program Files\MongoDB\Server\5.0\bin
C:\aliyun-cli
C:\vcpkg
C:\Program Files (x86)\NSIS\
C:\tools\zstd
C:\Program Files\Mercurial\
    C:\Program Files\Mercurial\msvcm90.dll => 9.00.30729.9518
    C:\Program Files\Mercurial\msvcp90.dll => 9.00.30729.9518
    C:\Program Files\Mercurial\msvcr90.dll => 9.00.30729.9518
C:\hostedtoolcache\windows\stack\2.15.7\x64
C:\cabal\bin
    ==> non existent
C:\\ghcup\bin
C:\mingw64\bin
C:\Program Files\dotnet
C:\Program Files\MySQL\MySQL Server 8.0\bin
C:\Program Files\R\R-4.4.0\bin\x64
C:\SeleniumWebDrivers\GeckoDriver
C:\SeleniumWebDrivers\EdgeDriver\
C:\SeleniumWebDrivers\ChromeDriver
C:\Program Files (x86)\sbt\bin
C:\Program Files (x86)\GitHub CLI
    ==> non existent
C:\Program Files\Git\bin
C:\Program Files (x86)\pipx_bin
C:\npm\prefix
C:\hostedtoolcache\windows\go\1.21.10\x64\bin
C:\hostedtoolcache\windows\Python\3.9.13\x64\Scripts
C:\hostedtoolcache\windows\Python\3.9.13\x64
    C:\hostedtoolcache\windows\Python\3.9.13\x64\vcruntime140_1.dll => 14.29.30139.0 built by: vcwrkspc
    C:\hostedtoolcache\windows\Python\3.9.13\x64\vcruntime140.dll => 14.29.30139.0 built by: vcwrkspc
C:\hostedtoolcache\windows\Ruby\3.0.7\x64\bin
C:\Program Files\OpenSSL\bin
C:\tools\kotlinc\bin
C:\hostedtoolcache\windows\Java_Temurin-Hotspot_jdk\8.0.412-8\x64\bin
    C:\hostedtoolcache\windows\Java_Temurin-Hotspot_jdk\8.0.412-8\x64\bin\msvcp140.dll => 14.16.27033.0 built by: vcwrkspc
    C:\hostedtoolcache\windows\Java_Temurin-Hotspot_jdk\8.0.412-8\x64\bin\vcruntime140.dll => 14.16.27033.0 built by: vcwrkspc
C:\Program Files\ImageMagick-7.1.1-Q16-HDRI
    C:\Program Files\ImageMagick-7.1.1-Q16-HDRI\msvcp140_1.dll => 14.38.33135.0
    C:\Program Files\ImageMagick-7.1.1-Q16-HDRI\msvcp140_2.dll => 14.38.33135.0
    C:\Program Files\ImageMagick-7.1.1-Q16-HDRI\msvcp140_atomic_wait.dll => 14.38.33135.0
    C:\Program Files\ImageMagick-7.1.1-Q16-HDRI\msvcp140_codecvt_ids.dll => 14.38.33135.0
    C:\Program Files\ImageMagick-7.1.1-Q16-HDRI\msvcp140.dll => 14.38.33135.0
    C:\Program Files\ImageMagick-7.1.1-Q16-HDRI\vcruntime140_1.dll => 14.38.33135.0
    C:\Program Files\ImageMagick-7.1.1-Q16-HDRI\vcruntime140_threads.dll => 14.38.33135.0
    C:\Program Files\ImageMagick-7.1.1-Q16-HDRI\vcruntime140.dll => 14.38.33135.0
C:\Program Files\Microsoft SDKs\Azure\CLI2\wbin
C:\ProgramData\kind
C:\ProgramData\docker-compose
C:\ProgramData\Chocolatey\bin
C:\Windows\system32
    C:\Windows\system32\msvcirt.dll => 7.0.20348.1 (WinBuild.160101.0800)
    C:\Windows\system32\msvcp_win.dll => 10.0.20348.1 (WinBuild.160101.0800)
    C:\Windows\system32\msvcp110_win.dll => 10.0.20348.1 (WinBuild.160101.0800)
    C:\Windows\system32\msvcp120_clr0400.dll => 12.00.52519.0 built by: VSWINSERVICING
    C:\Windows\system32\msvcp120.dll => 12.00.40660.0 built by: VSULDR
    C:\Windows\system32\msvcp140_1.dll => 14.32.31326.0
    C:\Windows\system32\msvcp140_1d.dll => 14.40.33810.0
    C:\Windows\system32\msvcp140_2.dll => 14.32.31326.0
    C:\Windows\system32\msvcp140_2d.dll => 14.40.33810.0
    C:\Windows\system32\msvcp140_atomic_wait.dll => 14.32.31326.0
    C:\Windows\system32\msvcp140_clr0400.dll => 14.32.31326.0
    C:\Windows\system32\msvcp140_codecvt_ids.dll => 14.32.31326.0
    C:\Windows\system32\msvcp140.dll => 14.32.31326.0
    C:\Windows\system32\msvcp140d_atomic_wait.dll => 14.40.33810.0
    C:\Windows\system32\msvcp140d_codecvt_ids.dll => 14.40.33810.0
    C:\Windows\system32\msvcp140d.dll => 14.40.33810.0
    C:\Windows\system32\msvcp60.dll => 7.0.20348.1 (WinBuild.160101.0800)
    C:\Windows\system32\msvcr100_clr0400.dll => 14.8.9037.0 built by: NET481REL1
    C:\Windows\system32\msvcr120_clr0400.dll => 12.00.52519.0 built by: VSWINSERVICING
    C:\Windows\system32\msvcr120.dll => 12.00.40660.0 built by: VSULDR
    C:\Windows\system32\msvcrt.dll => 7.0.20348.1 (WinBuild.160101.0800)
    C:\Windows\system32\vcruntime140_1_clr0400.dll => 14.32.31326.0
    C:\Windows\system32\vcruntime140_1.dll => 14.32.31326.0
    C:\Windows\system32\vcruntime140_1d.dll => 14.40.33810.0
    C:\Windows\system32\vcruntime140_clr0400.dll => 14.32.31326.0
    C:\Windows\system32\vcruntime140_threads.dll => 14.40.33810.0
    C:\Windows\system32\vcruntime140_threadsd.dll => 14.40.33810.0
    C:\Windows\system32\vcruntime140.dll => 14.32.31326.0
    C:\Windows\system32\vcruntime140d.dll => 14.40.33810.0
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0\
C:\Windows\System32\OpenSSH\
C:\Program Files\dotnet\
C:\Program Files\PowerShell\7\
    C:\Program Files\PowerShell\7\vcruntime140_cor3.dll => 14.38.33130.0
C:\Program Files\Microsoft\Web Platform Installer\
C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\
C:\Program Files\Microsoft SQL Server\150\Tools\Binn\
C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\
    C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\vcruntime140_cor3.dll => 14.29.30139.0 built by: vcwrkspc
C:\Program Files (x86)\WiX Toolset v3.14\bin
C:\Program Files\Microsoft SQL Server\130\DTS\Binn\
C:\Program Files\Microsoft SQL Server\140\DTS\Binn\
    ==> non existent
C:\Program Files\Microsoft SQL Server\150\DTS\Binn\
    ==> non existent
C:\Program Files\Microsoft SQL Server\160\DTS\Binn\
    ==> non existent
C:\Strawberry\c\bin
C:\Strawberry\perl\site\bin
C:\Strawberry\perl\bin
C:\ProgramData\chocolatey\lib\pulumi\tools\Pulumi\bin
C:\Program Files\TortoiseSVN\bin
C:\Program Files\CMake\bin
C:\ProgramData\chocolatey\lib\maven\apache-maven-3.8.7\bin
C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code
    C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code\msvcp110.dll => 11.00.65501.17010 built by: WINCCOMP(CGTBUILD13-VCWRKSPC)
    C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code\msvcp140_1.dll => 14.25.28508.3 built by: vcwrkspc
    C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code\msvcp140_2.dll => 14.25.28508.3 built by: vcwrkspc
    C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code\msvcp140.dll => 14.00.23026.0 built by: WCSETUP
    C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code\msvcr110.dll => 11.00.65501.17010 built by: WINCCOMP(CGTBUILD13-VCWRKSPC)
    C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code\vcruntime140_1.dll => 14.25.28508.3 built by: vcwrkspc
    C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code\vcruntime140.dll => 14.00.23026.0 built by: WCSETUP
C:\Program Files\Microsoft SDKs\Service Fabric\Tools\ServiceFabricLocalClusterManager
C:\Program Files\nodejs\
C:\Program Files\Git\cmd
C:\Program Files\Git\mingw64\bin
C:\Program Files\Git\usr\bin
C:\Program Files\GitHub CLI\
c:\tools\php
C:\Program Files (x86)\sbt\bin
C:\Program Files\Amazon\AWSCLIV2\
    C:\Program Files\Amazon\AWSCLIV2\VCRUNTIME140.dll => 14.38.33126.1
C:\Program Files\Amazon\SessionManagerPlugin\bin\
C:\Program Files\Amazon\AWSSAMCLI\bin\
C:\Program Files\Microsoft SQL Server\130\Tools\Binn\
C:\Program Files\LLVM\bin
    C:\Program Files\LLVM\bin\msvcp140_1.dll => 14.29.30139.0 built by: vcwrkspc
    C:\Program Files\LLVM\bin\msvcp140_2.dll => 14.29.30139.0 built by: vcwrkspc
    C:\Program Files\LLVM\bin\msvcp140_atomic_wait.dll => 14.29.30139.0 built by: vcwrkspc
    C:\Program Files\LLVM\bin\msvcp140_codecvt_ids.dll => 14.29.30139.0 built by: vcwrkspc
    C:\Program Files\LLVM\bin\msvcp140.dll => 14.29.30139.0 built by: vcwrkspc
    C:\Program Files\LLVM\bin\vcruntime140_1.dll => 14.29.30139.0 built by: vcwrkspc
    C:\Program Files\LLVM\bin\vcruntime140.dll => 14.29.30139.0 built by: vcwrkspc
C:\Users\runneradmin\.dotnet\tools
C:\Users\runneradmin\.cargo\bin
C:\Users\runneradmin\AppData\Local\Microsoft\WindowsApps

This is a bit of a mess. There is no real confidence in which MSVC runtime will be used.
The result was obtained in a workflow with this command:
foreach ($d in ($env:Path -split ';')) {
    Write-Output "$d"
    if (-not -not $d) {
        if (Test-Path -PathType Container $d) {
            Get-ChildItem "$d\*" -Include @("vcruntime*.dll", "msvc*.dll") |
                ForEach-Object { (Get-Command $_).FileVersionInfo } |
                ForEach-Object { Write-Output "    $($_.FileName) => $($_.FileVersion)" }
        }
        else {
            Write-Output "    ==> non existent"
        }
    }
}

Although I agree that the Github team should probably compile some non-trivial software with their runner images before deploying,

Compilation isn't the issue here. Running the compiled software is. They need to build and run some non-trivial software. (In my case the crashes happen whenever the applications that are being tested use std:mutex. If the test takes the app through a path that does not use std::mutex then it runs fine.)

Github what have you done!?
 Running the compiled software is. They need to build and run some non-trivial software. (In my case the crashes happen whenever the applications that are being tested use std:mutex. If the test takes the app through a path that does not use std::mutex then it runs fine.)

This is a weak assumption, what’s make you think that « they »are not Sufficiently test mutex ?

I hit this too, then protoc returned 0xc0000142

Also affected by this issue and, like some others here, the /D_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR workaround solved it for me. What a waste of time though! :exploding_head:

Compilation isn't the issue here. Running the compiled software is. They need to build and run some non-trivial software. (In my case the crashes happen whenever the applications that are being tested use std:mutex. If the test takes the app through a path that does not use std::mutex then it runs fine.)

This is a weak assumption, what make you think that « they »are not Sufficiently test mutex ?

I didn't claim they are insufficiently testing mutex. I simply said that in my case that is where the crash is happening. I do claim that they are insufficiently testing running software built with and running in the new runner environment.
Whatever the cause, the point is that a major breakage made it through their test and release system all the way to the production runner image without being detected. This is why I am requesting they conduct a post-mortem so they can figure out why and put in place steps to prevent it happening again.

Hello, we have identified a possible cause of DLL's version mismatch. TortoiseSVN tool when installed after VStudio overwrites files such as vcruntime140.dll and MSVCP140.dll under c:\Windows\system32. With PR DLLs are of the latest version which I have tested on two projects:

It fixes @ScottTodd 's segfaults when run from https://github.com/iree-org/iree/commit/29472a1637146514c2781c3befca34939c6e7480
Partially fixes @llvm-beanz's build issues https://github.com/microsoft/DirectXShaderCompiler. Release stage completes, Debug stage ends in warning C4201: nonstandard extension used: nameless struct/union treated as an error

We will start deployment with mentioned fix this week

@agarny

Also affected by this issue and, like some others here, the /D_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR workaround solved it for me. What a waste of time though! 🤯

It's more than a waste of time in the past few days (2 full days for me, multiplied by a few hundredths people in the same situation, meaning a loss of a couple man.years overall), it is also a waste of future time, because this "workaround" increases the technical debt. It forces an old behaviour in software, that will fall into oblivion, until it breaks in some future release, when the forced legacy behaviour becomes obsolete. And developers will spend hours tracking the issue, until they discover the old workaround and disable it, finally.
Really, thank you MS and GH for the situation...

I added the following to my CI run to check vcruntime140 versions:
((Get-Command vcruntime140.dll).Path)
C:\hostedtoolcache\windows\Python\3.9.13\x64\vcruntime140.dll
((Get-Command vcruntime140.dll).Version)

Major  Minor  Build  Revision
-----  -----  -----  --------
14     29     30139  0

((Get-Command C:/Windows/system32/vcruntime140.dll).Version)
14     32     31326  0

From this we see that (a) the runtime found on $env.PATH is an old one from the Python installation and (b) that the runtime installed in system32 is also old. 14.40.33810 is apparently needed for constexpr mutexes.
On my local Windows, which has VS Community, 14.40.33810 is installed in C:/Windows/system32.
It looks like C:/Windows/system32 has not been updated to the latest. Even if it was, builds will likely fail due to the old version included with Python.

Hello, we have identified a possible cause of DLL's version mismatch. TortoiseSVN tool when installed after VStudio overwrites files such as vcruntime140.dll and MSVCP140.dll under c:\Windows\system32. With PR DLLs are of the latest version which I have tested on two projects:

What about the older version from Python that appears earlier in $env.PATH?

Hello, we have identified a possible cause of DLL's version mismatch. TortoiseSVN tool when installed after VStudio overwrites files such as vcruntime140.dll and MSVCP140.dll under c:\Windows\system32. With PR DLLs are of the latest version which I have tested on two projects:

What about the older version from Python that appears earlier in $env.PATH?

+1, yes please, after all installations in the image, make sure that C:\Windows\System32 always comes first in Path.

@agarny

Also affected by this issue and, like some others here, the /D_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR workaround solved it for me. What a waste of time though! 🤯

It's more than a waste of time in the past few days (2 full days for me, multiplied by a few hundredths people in the same situation, meaning a loss of a couple man.years overall), it is also a waste of future time, because this "workaround" increases the technical debt. It forces an old behaviour in software, that will fall into oblivion, until it breaks in some future release, when the forced legacy behaviour becomes obsolete. And developers will spend hours tracking the issue, until they discover the old workaround and disable it, finally.
Really, thank you MS and GH for the situation...

Yes, I implemented the two workarounds mentioned here and here, and it worked fine for most of my tests, except for one where I need to build some Python bindings using pip install .. So, in the end, I decided to disable all of my Windows-related builds/tests. 🙄
I think that, overall, I lost the equivalent of nearly 3 working days (incl. a few hours here and there during my weekend!). I first experienced the issue after I upgraded a third-party library, so this is where I focussed my efforts, not thinking for a second that it could have been a GitHub-hosted Windows runner issue. Lesson learned!

We will start deployment with mentioned fix this week

Given the high volume of traffic in this issue, the consequences it entails (completely unusable workflows) and the impractical "workarounds", I would say this doesn't need a scheduled fix somewhen, but an urgent hotfix or rollback now.

This is also breaking most all of our GoogleTest runs in microsoft/msquic. I agree with the comments above that this must be addressed ASAP.

We are running into null exception errors when trying to run some command-line tools that we build. Error reported:
Cmd.exe exited with code '-1073741819'.

We've checked all code paths since May 26, which is the date of the last successful windows build. We've gone through the painstaking process of running each commit since to see if we can isolate the fix. Nothing works. Finally, I decided to run the May 26 build and it now fails as well. It's not our code. It's the environment.  This is a blocking issue as there are no workarounds available as we can't even get our tools to run (other than just not run any pipelines).

@mprather, welcome to the club 😟
If your applications are written in C++ and use mutexes, you may try to compile with the symbol which disables the constexpr constructor (see details in previous posts).

We are also in the club.
Two workarounds:

Setting _DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR, or
linking statically to the vc runtime.

But even better if the runner image is fixed.

If your applications are written in C++ and use mutexes, you may try to compile with the symbol which disables the constexpr constructor (see details in previous posts).

Thanks for the heads up. None of our code explicitly calls std::mutex but the libraries we depend on most likely do. I will have to scan our cached list of vcpkg binaries and determine the next course of action. Nice week and half of debugging pipeline failures, first gcc-13 was pulled, then clang on ubuntu fails, and now windows. All failures because the underlying images have been altered significantly.

Same problems here: https://github.com/Vertexwahn/FlatlandRT/runs/25907600653
For debug builds the problem does not happen. VS 2019 is not affected.

When an executable is built with VS 2022 17.10 (Release, x64) + _DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR, and linking dynamically to the vc runtime, is it then compatible with the latest Visual C++ Redistributable Version (14.40.33810.0)?

Issues #10019 and #10020, are the same root problem here. Is there any update on a resolution to fix these images?

It looks like things are back to normal...?

It looks like things are back to normal...?

Well, not quite. Two of my Windows tests now work again but another still fails.

We got runner image 20240610.1.0 this morning:

and the error error: SEH exception with code 0xc0000005 thrown in the test body. does not occur anymore.

We got runner image 20240610.1.0 this morning:

That's indeed the runner image used by two of my tests (after I rerun them), but my other test still uses the faulty runner image for some reasons (!?). Well, better push another commit...

@agarny did you succeed. I just pushed a commit to one of my branches/PRs and it still used the bad 20240603.1.0 image. How to you make it use the new image?

I just pushed a commit to one of my branches/PRs and it still used the bad 20240603.1.0 image. How to you make it use the new image?

You probably just need patience. https://github.com/actions/runner-images/ shows  . I suspect that it gets deployed on VMs by chunks and in the transition you randomly get either 20240603 or 20240610

@agarny did you succeed. I just pushed a commit to one of my branches/PRs and it still used the bad 20240603.1.0 image. How to you make it use the new image?

I didn't. It also used the 20240603.1.0 runner image even though it used the 20240610.1.0 runner image earlier when re-running previously failing tests. So, yeah, I gave up on trying to understand what happened. Best to wait for an official announcement.

For information, I just closed a related issue because it was fixed in the previous minutes. See https://github.com/actions/runner/issues/3331
The fix I mention is relative to this:

A workaround I found when reading https://developercommunity.visualstudio.com/t/Access-violation-in-_Thrd_yield-after-up/10664660#T-N10668856 is that you can define "/D_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR" when building your software to revert to a std::mutex constructor compatible of older vcruntimes : https://github.com/rouault/gdal/commit/c4ab31f0eb1c196dff2d561292a29d8840223790 . My builds work fine with that workaround.

DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR seems to not be needed anymore.

Tests of my project's Java binding still fail in 2<IP_ADDRESS>.0 as reported by @rouault in #10055. Personally I wouldn't have opened a new bug as to me it is part of the breakage introduced by 2<IP_ADDRESS>.0 so covered here. Surprisingly the test of my project's Python binding now works. Surprising because the first vcruntime140.dll in $env:PATH is still the old one in C:\hostedtoolcache\windows\Python\3.9.13\x64\vcruntime140.dll. I will have to check if my Python binding test is exercising any of the multithreaded code in the underlying library.

Tests of my project's Java binding still fail in 2<IP_ADDRESS>.0 as reported by @rouault in #10055. Personally I wouldn't have opened a new bug as to me it is part of the breakage introduced by 2<IP_ADDRESS>.0 so covered here. Surprisingly the test of my project's Python binding now works. Surprising because the first vcruntime140.dll in $env:PATH is still the old one in C:\hostedtoolcache\windows\Python\3.9.13\x64\vcruntime140.dll. I will have to check if my Python binding test is exercising any of the multithreaded code in the underlying library.

FWIW, I don't have Java bindings in my project, but I do have Python bindings (using pybind11) and my Python-related tests still fail on Windows while everything is back to normal when it comes to my C++-related tests.

Just adding some info -- our C++ tests are still failing even with the new 610 hosted image. We rely on dlls created with an older runtime. We've never had an issue building and then running new tools that rely on these 3rd party dlls, until the new hosted image arrived.

I encountered a new problem in 2<IP_ADDRESS>.0. Previously this line in the jobs.env: section
CMAKE_GEN: ${{ matrix.generator }}

resulted in the environment variable not being set if matrix.generator was not set. In 2<IP_ADDRESS>.0 it results in CMAKE_GEN being set to an empty string. Our build script sets a default generator if CMAKE_GEN is not set. As the variable is set, the default isn't set and CMake config fails. I fixed this by setting generator in every part of the matrix.

FWIW, I don't have Java bindings in my project, but I do have Python bindings (using pybind11) and my Python-related tests still fail on Windows while everything is back to normal when it comes to my C++-related tests.

Thanks. Probably our Python test is not exercising any multi-threaded code in the underlying library.

FWIW, I don't have Java bindings in my project, but I do have Python bindings (using pybind11) and my Python-related tests still fail on Windows while everything is back to normal when it comes to my C++-related tests.

Thanks. Probably our Python test is not exercising any multi-threaded code in the underlying library.

Our test is exercising multi-threaded code. I do not know why your tests still fail in 2<IP_ADDRESS>.0 @agarny while mine work.

Our test is exercising multi-threaded code. I do not know why your tests still fail in 2<IP_ADDRESS>.0 @agarny while mine work.

I have just had a look at my Python-related test and most of it is fine and it's not related to the multi-threaded aspect of this issue. My test fails when trying to build my project using pip install . which is done using skbuild and, for some reasons, it's not able to copy a file. Anyway, all I know is that it all used to work fine before 2<IP_ADDRESS>.0. So, I am going to wait for this issue to be considered fixed before concluding anything.

@llvm-beanz - Does your issue got fixed, as we did the image deployment. If your facing same issue ,kindly let us know.

I had a problem similar to the OP on my CI and now it's fixed after the latest deployment.
Thanks!

Run this script:
Get-ChildItem -Path "C:\hostedtoolcache\windows" -File -Include msvcp*.dll,concrt*.dll,vccorlib*.dll,vcruntime*.dll -Recurse | Remove-Item -Force -Verbose

You don't have a reason not running it.

The fact that it takes over 15 minutes does count as a reason to me: https://github.com/ruffle-rs/ruffle/actions/runs/9512755132/job/26221430721?pr=16713
And it doesn't fix the problem.

Bad news, the last updated runner does not fully work. Specifically, Java applications using JNI (Java Native Interface) still fail. The DLL which is called in the Java application is built and tested in the runner. Reverting to the _DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR trick makes the applications work again, Java included.
See https://github.com/actions/runner-images/issues/10020#issuecomment-2168449045
Interestingly, Python applications do not fail when calling the same DLL (the project has Java and Python bindings).

Java applications using JNI (Java Native Interface) still fail

Run the following command will solve the issue:
Get-ChildItem -Path "C:\hostedtoolcache\windows" -File -Include msvcp*.dll,concrt*.dll,vccorlib*.dll,vcruntime*.dll -Recurse | Remove-Item -Force -Verbose

Python applications do not fail

Because python.exe is written in pure C. The ABI change in VS 2022 17.10 is for C++.

@snnn

Run the following command will solve the issue:
Get-ChildItem -Path "C:\hostedtoolcache\windows" -File -Include msvcp*.dll,concrt*.dll,vccorlib*.dll,vcruntime*.dll -Recurse | Remove-Item -Force -Verbose

Running this command takes 28 minutes 51 seconds to find and delete 38 files. It is not an acceptable solution to run before each CI job. Another user reported it took 15 minutes and did not solve the issue. So, no, sorry.

@lelegard , it depends on how you got the Java runtime. If the java.exe that was used for running the tests in your pipelines was in the C:\hostedtoolcache\windows folder, then the command above can solve the issue.

@snnn

it depends on how you got the Java runtime. If the java.exe that was used for running the tests in your pipelines was in the C:\hostedtoolcache\windows folder,

Continuous integration needs a reproducible build, especially for Java where so many versions exist. The workflow downloads and install all its pre-requisites. Java comes from adoptium.net, the de-facto standard for Java deployment on Windows nowadays.
All CI tests pass on local Windows machines, as used by maintainers and contributors. It used to work on the CI until the infamous update of last week. It no longer works in the CI runner, even after today's "fix". So, the CI runner remains broken and must be fixed.

FWIW, I don't know whether the 20240610.1.0 runner image is considered to be fine (probably not since this issue is still open!), but just in case it's still broken for me. I have a C++ project with some Python bindings and one of the steps in my Windows CI is to pip install . using scikit-build. It all used to work fine before the 20240603.1.0 runner image, but now it's broken (while it's fine on Linux and macOS). So, for the GitHub devs, you might want to check this which is my hack (!!) to get the 20240610.1.0 runner image to work for my needs since I really need and want my Windows jobs back.

HI @llvm-beanz ,
we hope you're issue got resolved after deploying the latest version , Please share your comments on it .

@kishorekumar-anchala, the latest image seems to work for us.
There has to be a better way to resolve issues like this more quickly. This was an enormous disruption to our team and teams across the world.
Do you have some sort of RCA that you've performed which captures how you can prevent issues like this in the future and/or respond more quickly to them if the occur?

For those interested in seeing the root cause (the unversioned MSVC runtime causing UB crashes instead of a noisy but explanatory at-startup failure) fixed, upvote my “reconsider” comment here: https://developercommunity.visualstudio.com/t/Access-violation-in-_Thrd_yield-after-up/10664660#T-N10669129-N10678728

@kishorekumar-anchala, the latest image seems to work for us.
There has to be a better way to resolve issues like this more quickly. This was an enormous disruption to our team and teams across the world.
Do you have some sort of RCA that you've performed which captures how you can prevent issues like this in the future and/or respond more quickly to them if the occur?

@kishorekumar-anchala: I concur with @llvm-beanz's RCA proposal. The number of man hours spent on investigations is astonishing.  Only to come the resolution that it wasn't our fault. This cost us 3 days before finding this specific ticket that offered some insight. Couple that with inability to run tests for days on end before some resolution was on the horizon -> this was a very expensive break and disrupted delivery schedules. Now fold in everyone else that scrambled in a similar fashion. And for some, the image is still effectively broken and still running up the tab.
I have never considered Azure hosted images to be unreliable until now. There was no communication that an image was being updated in a substantial form. No real way to figure out if the issue was known or being addressed.
This lack of communication also bit our team the week prior when we learned (via series of failed tests) that gcc 13 had been pulled off a set of images without any meaningful announcements.  Some might argue that the gcc changes might be posted via tasks in the runner repos but I don't monitor them. Instead, I always reference a page such as Microsoft-hosted agents to understand the current config opportunities and scan the updates list. I've never seen images degrade in tooling and stability as they have in the past few weeks. Please consider how to inform customers more effectively as well as responding more efficiently.

Like others, I really wish there was more and better communication from the team. The 20240610.1.0 runner image still doesn't work for my project (see above) and nanobind (see here), which I want to be able to use.

@llvm-beanz -
We are closing this issue, as your builds were failing are now successful after the 20240610 image deployment and are fixed.
https://dev.azure.com/DirectXShaderCompiler/public/_build/results?buildId=6395&view=results
https://dev.azure.com/DirectXShaderCompiler/public/_build?definitionId=1&_a=summary
Thank you. Kindly reach out to us if you still face any new issues.

@llvm-beanz - We are closing this issue, as your builds were failing are now successful after the 20240610 image deployment and are fixed.
https://dev.azure.com/DirectXShaderCompiler/public/_build/results?buildId=6395&view=results https://dev.azure.com/DirectXShaderCompiler/public/_build?definitionId=1&_a=summary
Thank you. Kindly reach out to us if you still face any new issues.

@ijunaidm Do you have more information on this change.  In our case, JVM itself is loading an older version of vc runtime from it's deployed folder, so even if we remove or update the vc dlls in system32 and other paths on the agent image, JVM still loads an older version of the runtime before we are even called, so our native code will crash on load if we build on the latest 20240610.
The 20240610 image in un-usable to us, unless we modify our code, and work with all our partner team to have them also start building with the  D_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR flag defined.
This does not seem like a good path forward.  How long will the D_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR be supported? What other std incompatibilities are in there that we do not know about yet, and are not covered by this one compiler flag?
Do you know if there is a customer impact issue for this in the DevDiv team?

@kishorekumar-anchala, the latest image seems to work for us.
There has to be a better way to resolve issues like this more quickly. This was an enormous disruption to our team and teams across the world.
Do you have some sort of RCA that you've performed which captures how you can prevent issues like this in the future and/or respond more quickly to them if the occur?

@kishorekumar-anchala: I concur with @llvm-beanz's RCA proposal. The number of man hours spent on investigations is astonishing.  Only to come the resolution that it wasn't our fault. This cost us 3 days before finding this specific ticket that offered some insight. Couple that with inability to run tests for days on end before some resolution was on the horizon -> this was a very expensive break and disrupted delivery schedules. Now fold in everyone else that scrambled in a similar fashion. And for some, the image is still effectively broken and still running up the tab.
I have never considered Azure hosted images to be unreliable until now. There was no communication that an image was being updated in a substantial form. No real way to figure out if the issue was known or being addressed.
This lack of communication also bit our team the week prior when we learned (via series of failed tests) that gcc 13 had been pulled off a set of images without any meaningful announcements. Some might argue that the gcc changes might be posted via tasks in the runner repos but I don't monitor them. Instead, I always reference a page such as Microsoft-hosted agents to understand the current config opportunities and scan the updates list. I've never seen images degrade in tooling and stability as they have in the past few weeks. Please consider how to inform customers more effectively as well as responding more efficiently.

Initially I don't think this in on the hosted image maintainers.  My point of view is that this is a failure on the Visual Studio team that allowed such a change to ship in the first place.  The only area the hosted image folks could have improved would be to have rolled back the compiler upgrade as soon as they realized what happened, and to then message it to the community and push back on the Compiler team to unbreak the STD classes in the vc runtime.... or at a bare minimum published a high visibility  breaking change message as soon as they root caused the issue?

In our case, JVM itself is loading an older version of vc runtime

@BrianMouncer #10020 and #10055  also cover the JVM issues.

Initially I don't think this in on the hosted image maintainers.

It is. They deployed an image in which the VC runtime installed in C:\Windows\system32 did not match the version of the image's compiler,  so all tests running newly compiled code failed. They also, as you said, should have rolled back the image as soon as the magnitude of the issue became apparent.
As for MS, they need to fix the compiler tool chain so that the dynamic linker ensures code is linking to a compatible version of the runtime and fails with an understandable error message when the versions mismatch.

Initially I don't think this in on the hosted image maintainers.

@BrianMouncer It's a maintainer's issue. I have no gripes with the VC team, as a matter of fact.  The images were improperly built. As supporting evidence, we re-ran pipelines that had previously succeeded with May's image and found those pipelines failed with the new June image. Then that same code started working again when the 20240603.1.0 image was deployed. That is not a code issue and certainly not a runtime issue. It's an image configuration issue.
We lucked out that our 3rd party libraries started working with the fix. We never had to touch our code b/c it never explicitly dealt with mutex issue. So, yes, magically on the 13th of the month, everything started working for us with no code change. It's an image issue. The sticky part is the issue still exists for some - #10020 is still active and very much a concern for a lot of folks since the new configuration is still a blocking issue for them.
It's worth noting that the reason I also called out the gcc issue was to illustrate that two different platforms suffered from the lack of clear communication, and both practically happened at the same time. That's a lot of expensive deviations due to debugging, workarounds, etc. The windows issue illustrates a need for better testing, monitoring, and response. The ubuntu issues took an image set backwards. Both issues highlight a lack of communication. We spent a lot of time (man hours and pipeline time) on issues that really shouldn't have happened in the first place (windows c++ issue) or, at the very least, with sufficient notice to allow for planned changes (ubuntu issue).

Is the  #define _DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR workaround needed with clangcl as well as msvc?.

Is the #define _DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR workaround needed with clangcl as well as msvc?.

I found my own answer after looking back at CI build logs. Usually an msvc build failed first cancelling the other builds but I found an occurrence where the runner image was updated after the msvc jobs had completed but before a clangcl jobs. It suffered crashes and SEH exceptions in the way familar to everyone here. The workaround is needed also with ClangCL..


CHAPTER 43

I'm interested in chapter 43, when this chapter's source code would upload?

Hi @wyzwzz - all code associated with Chapter 43 is in code listings in the chapter's text.


Guarantee offsets for , , ,

This change guarantees special tokens , ,  and  in that order.
It creates an Offsets object in baseline/utils.py that provides the offsets and their values.
Also refactored baseline/w2v.py to generically preset these vectors and removed quirky
constructor params from seq2seq modules to simplify things.
Additionally, we ensure that the first 3 Offsets are also in the label vectorizer for tagging

I don't know if it is useful but you can make offsets iterable and star unpackable like this
from six import with_metaclass
from collections import Mapping

class Unpackable(type):
    def __iter__(self):
        for x in self.VALUES:
            yield x

    def __getitem__(self, item):
        item = item[1:-1]
        return getattr(self, item)

    def __len__(self):
        return len(self.VALUES)

class UnpackableMapping(Unpackable, Mapping): pass

class Offsets(with_metaclass(UnpackableMapping)):
    PAD, GO, EOS, UNK, OFFSET = range(0, 5)
    VALUES = ['<PAD>', '<GO>', '<EOS>', '<UNK>']

>>> from off import Offsets
>>> for x in Offsets:
...     print(x)
...
<PAD>
<GO>
<EOS>
<UNK>
>>> dict(**Offsets)
{'<PAD>': 0, '<GO>': 1, '<EOS>': 2, '<UNK>': 3}
>>> print(*Offsets)
<PAD> <GO> <EOS> <UNK>

This is a good idea and it seems like it will be compatible with my change in this PR.  For now, I will merge the PR, and we can do this separately when there is a bit more time.


implement named client support: open-feature/spec@4cf8229

Add named client support to the JS SDK based on the recent update to the spec: https://github.com/open-feature/spec/commit/4cf8229d23a88feeaadf8b066e5d3662b94ff262
This feature has already been implemented in Java. It can be used as a reference for the JS implementation.
https://github.com/open-feature/java-sdk/pull/388

But wouldn't this be a problem because of the breaking change?
If I get it right, this would remove the version from it, so current implementations would be broken.

I talked to @lukas-reining about overloading the method and documenting the purpose of each property. The client's name will have meaning after this chance, but only if the name matches a registered provider. The version remains purely informational and doesn't affect runtime behavior.
The overload could look something like this.
getClient(context?: EvaluationContext)
getClient(name: string, context?: EvaluationContext)
getClient(name: string, version: string, context?: EvaluationContext)
getClient(nameOrContext?: string | EvaluationContext, VersionOrContext?: string | EvaluationContext, context?: EvaluationContext)

I talked to @lukas-reining about overloading the method and documenting the purpose of each property. The client's name will have meaning after this chance, but only if the name matches a registered provider. The version remains purely informational and doesn't affect runtime behavior.
The overload could look something like this.
getClient(context?: EvaluationContext)
getClient(name: string, context?: EvaluationContext)
getClient(name: string, version: string, context?: EvaluationContext)
getClient(nameOrContext?: string | EvaluationContext, VersionOrContext?: string | EvaluationContext, context?: EvaluationContext)

This all sounds right to me.


Angular CLI has changed some of the generated outputs

The instructions for angular.json in step 2 under the "Update the app" indicate that a defaults object should be modified. For one, this file is now called "angular.json", not ".angular-cli.json". For another, this apparently stopped producing a defaults object, so the instructions for #1 need to be updated.
The example to use in the start script specifies that the following should be set:
"start": "ng serve --ssl true --port 3000"
Rather, I recommend this be updated with the following, and no changes being made to angular.json.
"start": "ng serve --ssl true --ssl-key 'certs/server.key' --ssl-cert 'certs/server.crt' --port 3000"

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: fd013f4f-384b-49b8-152d-023ce8ec5bae
Version Independent ID: 3700e56b-302c-ae2b-79bf-16702aeadcff
Content: Build an Excel add-in using Angular
Content Source: docs/quickstarts/excel-quickstart-angular.md
Product: office
GitHub Login: @o365devx
Microsoft Alias: o365devx

Thanks. We'll take a look at this.
MS internal: https://office.visualstudio.com/OC/_workitems/edit/2508542

@WhitWaldo we've significantly revised this quick start, to reflect that the Yeoman generator for Office Add-ins is now the recommended way of generating an Office Add-in project using the Angular framework. Please give the new instructions a try and feel free to reach out again if you have any trouble.

This is so frustrating!!! This should be simple and consistent, however, apparently a lot of devs can't get the angular to work as explained above. What's really annoying, is that a YouTube video from a random person from 2016 is the "explanation" of one of the key components of the add-in. I've noticed that several devs can't get it to work during my research.
How come Microsoft doesn't offer something more robust? For example, the JQuery Excel add-in is great, however, I really need to use Angular for my project. Well, hours and hours wasted already.

Yo office command throwing an error and unable to generate project template. Any link to working solution highly appreciable.

@VenkatSAP sorry to hear that you're having trouble. If you can please create a new issue in the OfficeDev/generator-office repository (and include info about repro steps and the error message that you're seeing), someone will assist you there.

Is there a way where we can run Angular solution on Visual Studio and not go by Yeomen generator


Move to Dagger2?

Hey Vackosar,
you've probably noticed that Roboguice is deprecated since August 2016.  What do you think about moving to Dagger2? This also could optimize the performance as it's faster than Roboguice. I could also help in December to realize the migration.
Cheers!

I didn't like Dagger 2 in the past. RoboGuice is really convenient. Is there something more similar to RoboGuice?


The feature "Format On save" doesn't work for RLS.

I think this is true for checkOnSave as well. VSCode says its an unknown configuration setting.

@bjrnt,
"Action On Save" works well for RLS.

It seems VSCode does have "editor.formatOnSave" parameter.
I am going to remove the extension's parameter.

I have done it in https://github.com/KalitaAlexey/vscode-rust/pull/74

Thanks for your work on the extension @KalitaAlexey
Google has brought me here several times trying to work out how to get formatting working with RLS in vscode. Per the docs you may need to do this:
Create a rls.toml file in your project's root and add unstable_features = true and RLS will be able to auto format on save and renaming.


Test compound object manifests in the IIIF validator

Compound images appear to be ok
Test audio, video, pdf compounds

Tested the audio, video, and pdf compound manifests, with no validator errors


Task1: Write your first C# code

Closing this issue as the related PR Set1Task1: Write your first C# code #2 is closed


Add version check caching, fix version comparison

This PR introduces the following changes:

Version checking cache:
Currently, version checking works by making an HTTP request to PyPI on every call. To avoid repetitive network requests, we implement a caching mechanism using a local file, ensuring that requests are only made once a day at most.
Improved version comparison:
The current version comparison logic relies on integer comparisons, which do not support letters and may lead to errors in cases like "6.0.15" vs "6.1.0". The new comparison mechanism is more robust and powered by the version handling capabilities of the packaging library.
Fix for version_checking silent failure issue:
The CLI module includes logic for displaying an error message with a tip to disable version checking in case of a network request failure. However, this code is unreachable due to version checking failing silently.
This PR introduces a new check_version function with a custom exception. The old behavior is retained with a display of a deprecation warning.
The new function name should also be more descriptive to an end user.

@olzhasar-reef thank you for the contribution!

@ibraheem-opentensor do you mind testing this when you get a chance?

@gus-opentensor  Lgtm!

@gus-opentensor I've merged recent changes from the staging branch addressing conflicts.
Let me know if there's anything else preventing from merging this PR.


Input-Plugin-Reference

Need an input plugin for referencing one piece of content from another.
Feature: Input-Plugin-Reference
  As a core developer
  I want to implement an input plugin
  So that user may reference one piece of content to other

  Scenario: Reference one content type from all content types
     Given user wants to reference one content type
     When I implement an input plugin
     Then I should be able to indicate the number of references the user may choose

  Scenario: Reference a piece of content from one content type
    Given user wants to reference one piece of content
      And API supports retrieval of content
     When I implement an input plugin
     Then I should be able to indicate the content type
       And I should be able to indicate the number of references the user may choose
       And I should be able to indicate selection of content according to its state.

  Scenario: Reference a revision from one piece of content from one content type
     Given user wants to reference a revision from one piece of content
      And API supports retrieval of content
     When I implement an input plugin
     Then I should be able to indicate the content type
      And I should be able to indicate the content from the content type
      And I should be able to indicate the number of references the user may choose
      And I should be able to indicate selection of content according to its state.

  Scenario: Reference an attribute from one piece of content from one content type
     Given user wants to reference an attribute from one piece of content
      And API supports retrieval of content
     When I implement an input plugin
     Then I should be able to indicate the content type
      And I should be able to indicate the content from the content type
      And I should be able to indicate the number of references the user may choose
      And I should be able to indicate selection of content according to its state.

  Scenario: Reference an attribute from one revision of one piece of content from one content type
     Given user wants to reference an attribute from one revision of one piece of content
      And API supports retrieval of content
     When I implement an input plugin
     Then I should be able to indicate the content type
      And I should be able to indicate the content from the content type
      And I should be able to indicate the number of references the user may choose
      And I should be able to indicate selection of content according to its state.

Input Plugin Reference

[ ] Input Plugin Reference / Reference one content type from all content types
[ ] Input Plugin Reference / Reference a piece of content from one content type
[ ] Input Plugin Reference / Reference a revision from one piece of content from one content type
[ ] Input Plugin Reference / Reference an attribute from one piece of content from one content type
[ ] Input Plugin Reference / Reference an attribute from one revision of one piece of content from one content type

@scottnath @Snugug
require some thoughts over state:

is it publishable?
is it live?
is it the latest revision?
only content which has completed approval?
unapproved content

Duplicate of https://github.com/punchcard-cms/punchcard/issues/45


Calico-apiserver pods are all restarting on change to extension-apiserver-authentication Configmap causing webhooks to fail

Expected Behavior
calico-apiservers should always be available to service webhooks.
Current Behavior
Currently when calico-apiserver pods detect a change to the extension-apiserver-authentication ConfigMap in the kube-system namespace they all terminate with exit code 0 causing the kubelet to restart them.  During this time they are not available to handle webhooks and so can cause issues with deployments.
The following logs lines are show.
time="2024-02-06T18:40:58Z" level=info msg="Main client watcher loop"
I0206 18:41:24.185839       1 run_server.go:64] Detected change in extension-apiserver-authentication ConfigMap, exiting so apiserver can be restarted

Possible Solution
calico-apiserver should either not restart on changes to the extension-apiserver-authentication Configmap and load the changes it needs
OR
Trigger a rolling restart of the deployment to ensure only one pod is down at a time.
Steps to Reproduce (for bugs)
Trigger a change to the extension-apiserver-authentication Configmap in the kube-system namespace.
Context
Our CI is failing periodically because the webhooks are not available.
We are getting alerts for pods restarting.
Your Environment

apiserver:v3.27.0
AWS EKS
Amazon linux

@caseydavenport

Just giving my 2 cents, but keep in mind I don't know much about calico-apiserver and I'm coming from having some experience doing KTHW and setting this stuff up for the datadog-cluster-agent's implementation of the custom metrics API, so I may say some stuff that's a taller order than I think it is.

The only caveat here is that I believe there are some possible changes to the extension-apiserver-authentication configmap that would invalidate all running apiservers, so a rolling update would potentially be slower than desired. That configmap contains the certs needed to authenticate with the main Kubernetes API server, so if those certificates change it's quite possible your Calico API servers won't be functional anyway.

As long as the signing CA root for the certs in the extension-apiserver-authentication ConfigMap doesn't change, then I don't think it's going to make all the API servers non-functional. You can have requestheader-client-ca-file in that ConfigMap change its value without things breaking, since that file can be a cert bundle containing an intermediate CA (it is on my cluster, at least.) I am 90% certain I recall rotating the intermediate CA without things breaking.
Regardless, since it is a matter of the client cert you are presenting being rejected or not, I think that's kind of moot; you would just reinitialize your K8s client if you get an SSL error saying your cert was rejected. You already are proactive when you see changes to the ConfigMap, so I think you just need to make the action you take to be to reinitialize the K8s client. I assume that whatever concurrency you have going on will make that easier said than done, but hopefully it is not too hard to finagle.
AFAICT, we never have this problem with the custom metrics API backed by the datadog-cluster-agent, so I do believe this is possible to accomplish without the pods restarting themselves.

Add a config option to disable that restart in the Calico API server, so it doesn't restart itself on change.
Instead, make sure we use an annotation of the hashed configmap contents, applied to the pods from the tigera/operator.

I believe that an approach like this will be kind of annoying to end-users; my team right now is just rewriting our monitors to be less sensitive to calico-apiserver restarting because that is easier than having to finagle stuff with the tigera operator. But, I am ignorant about how calico-apiserver's internals work, so maybe this is the only feasible solution for some reason, so I don't want to discredit it. I'm mostly just saying that as an end-user, I wouldn't want to have to set some config option that by all reasonable accounts should just be the default behavior, and I wouldn't want to have to interact with the tigera operator in any capacity to facilitate this behavior that I would want to be the default. As an end-user, I would want things to just transparently work without interruption if possible. If that's not done by refreshing a K8s client when a ConfigMap change is detected, then that's fine, I would just want it to be hands-off, if possible.
Hopefully my comment gives you some good ideas or a good lead toward a solution, and you forgive me for speaking in generalities since I don't know calico-apiserver's internals. Thank you very much!

The rolling update approach was my first though just because it ensures that, speaking generally, changes that result in a "bad" configuration can be caught by a hung upgrade. But I'm not super attached to that.
If we can manage to simply recreate the client using the new configuration, I am good with that!


Add FAQ page about dispatching browser events

Resolves #352 by adding a new page in the FAQ that describes usage of browser APIs to programatically dispatch events

Thanks for your work. However, the underlying issue was resolved in the meantime. See https://github.com/reactjs/reactjs.org/issues/352#issuecomment-678797498 for more information.


Periodically update unrealized pnl for position in database

stacked on top of https://github.com/get10101/10101/pull/966
Note: I did not bother setting the unrealized_pnl to null when we close the position. Not sure that's actually necessary.
fixes: #932

bors r+


feat: series.rename

I keep reaching for this and realising it doesn't exist
reference: https://docs.pola.rs/api/python/stable/reference/series/api/polars.Series.rename.html

I will take it


compactified CQM equations

NFC
The two separate equality and inequality constraints in the ConstrainedQuadraticModel docstring are replaced with single more compact notation that also reflects the structure of the class.

Codecov Report

Merging #1243 (bdbe9eb) into main (5d2043d) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1243   +/-   ##
=======================================
  Coverage   94.89%   94.89%
=======================================
  Files          83       83
  Lines        8208     8208
=======================================
  Hits         7789     7789
  Misses        419      419

Impacted Files
Coverage Δ

dimod/constrained.py
94.68% <ø> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

@JoelPasvolsky For the \circ symbol, that is used in some publications, e.g. equation 2.1 in this publication. For the Ocean docs, I can make an accompanying PR, maybe after merging this?

@JoelPasvolsky For the \circ symbol, that is used in some publications, e.g. equation 2.1 in this publication. For the Ocean docs, I can make an accompanying PR, maybe after merging this?

Thanks, yes, I meant that the SDK update would be a different PR, it was just so we would keep it in mind.

@alexzucca90, I'm doing a little A/B testing and will get back to you soon.

It might be slightly clearer to use \bigcirc, but have not tested it myself to be sure.


Document functions at all

Sami does not manage to get this documentation:
if ( ! function_exists( 'get_term_meta' ) ) {
	/**
	 * Retrieve term meta field for a term.
	 *
	 * @since 1.1.0
	 *
	 * @param int    $term_id  Term ID.
	 * @param string $meta_key The meta key to retrieve.
	 *                         By default, returns data for all keys.
	 * @param null   $single   Whether to return a single value. Default false.
	 *
	 * @return mixed Will be an array if $single is false.
	 *               Will be value of meta data field if $single is true.
	 */
	function get_term_meta( $term_id, $meta_key = '', $single = null ) {
		return get_metadata( 'term', $term_id, $meta_key, $single );
	}
}

Is it my syntax or why doesn't it show up in the documentation?
Here is my config: https://github.com/sourcerer-mike/wp-comfort/blob/feature/term-meta/tests/sami.php

Does Sami even handle globally defined functions?

If this is the case, then I change the feature request to "Handle functions in any scope".
I really hope they do.

Sami doesn't support global procedural functions, unfortunately. See #49.

This can be closed because, #49 issue is about the same topic and is closed as well.


Package punkt is already up-to-date! File extension is not allowed.

I translate pdf. and program presented Package punkt is already up-to-date! File extension is not allowed. how do you resolve it ？

The example pdf on Google Colab works fine. Try it again and providing your pdf file can help if the problem persists.


Onboard small screens fix

⚠ IMPORTANT: Please do not create a Pull Request without creating an issue first.
All changes need to be discusssed before proceeding. Failure to do so may result in the pull request being rejected.
Please be sure to review our Code of Conduct, Contributing Guidelines, and Support documentation before submitting a pull request.

Please include the issue number the pull request fixes by replacing YOUR-ISSUE-HERE in the text below.
Fixes #686
Summary
1- changed the variant of  the questions from subtitle2 to body1
2- changed the grid of the questions to 5 inside of 6

Details

Test Plan (required)

Final Checklist

[x] For CoronaTracker, did you bump the version in package.json?

Update the second decimal for a major change
Update the third decimal for a minor change
Numbers can go past 9, e.g. 1.0.9 => 1.0.10
For more info, read about Semantic Versioning

[ ] Did you add any new tests as necessary?
[x] Is your PR rebased off the most current master?
[x] Have you squashed all commits? (can be done at merge)
[x] Did you use yarn not npm? (important!)
[x] Did you use Material-UI wherever possible?
[x] Did you run yarn lint on the code?
[x] Did you run all of your most recent changes locally to make sure everything is working?

none I can replace it with 6em

Mixing px and em is confusing and I think I personally prefer px across the board because of this confusion.
However, I see em's worth in some cases. One case in OnboardUser is in the saveButton class. It's height is 3.5em. I don't actually know what that value is in px off the top of my head, but I know that it is greater than the current font size, 1em, which makes sense because the button's height should be greater than the font size.
Now back to the confusion part: In this same component the leftButton class uses px for its height. This lack of consistency is what I don't like.
@SomeMoosery

@acthelemann I agree with consistency point. Personly I like using px, but as you said especially with fonts, I use em/rem


jsonp middleware

Fixed #658

Current coverage is 59.15% (diff: 0.00%)

Merging #659 into master will decrease coverage by 0.30%

@@             master       #659   diff @@
==========================================
  Files           197        198     +1
  Lines          4322       4341    +19
  Methods        4017       4034    +17
  Messages          0          0
  Branches        303        305     +2
==========================================
- Hits           2570       2568     -2
- Misses         1752       1773    +21
  Partials          0          0

Powered by Codecov. Last update fa05f71...e3ba7fb

👍


/zh-CN/docs/Web/CSS/var

Request type

[ ] Please close this issue, I accidentally submitted it without adding any details
[ ] New documentation
[x] Correction or update

Details

The translation of “fallback value” is “回退值” in this document. Which is hard to understand in chinese. Better translation is “后备值” or “备选值” .

I've tried to fix this. I've replaced the string of characters where they appear as a separate word.


issue #605 Reading Challenge and Progress Tracking

Under the features section of the About Button I have added options of Reading Challenge and Progress Tracking. Now I will be working on adding various features to the added two options. Working under gsoc'23

Related Issue
Closes #issue_number

Description

Screenshots

Checklist

[x] My code adheres to the established style guidelines of the project.
[x] I have included comments in areas that may be difficult to understand.
[x] My changes have not introduced any new warnings.
[x] I have conducted a self-review of my code.

I'm working on issue #605

@Suchitra-Sahoo please attach screenshot of the changes you've made and mention the issue number

issue #605


trigger GitHub actions

updates in MASE repo requires a re-build of docker, it seems like somehow the automatic rebuild was stopped, hence thtis PR to od a manual rebuild.


update cuda cmake code

Hi @lindstro, some students I am working with encountered problems building the CUDA version of ZFP using a new version of CMake (v3.27 and newer).  This is because the FindCUDA cmake package was disabled in favor of FindCUDAToolkit and CUDA language support in this version and will be removed in a future version after being deprecated in 3.10.  The replacement features were introduced in cmake 3.17, but I find they are stable after 3.20 (the new cmake minimum required version that I introduced here).
As I have documented here: https://robertu94.github.io/guides/dependencies.html#tooling-versions, cmake 3.20 is available on all major Linux distros for their normal support cycles except Ubuntu 20.04, and CMake 3.20 is available on this platforms via pip install cmake or other package management systems including spack.  Supporting cmake 3.17 also includes CentOS-7 until it is deprecated in July, but will not support Ubuntu 20.04 which only provides cmake 3.16.
Regardless if you adopt this patch or not the spack package for ZFP needs to be updated as it does not build the cuda variant after cmake 3.27 to something of the effect of depends("cmake@:3.26", when="@:1.0.0+cuda")
cc: @jtian0

@robertu94 I appreciate the contribution and would like to merge your PR, though we first need to find a workaround for the AppVeyor tests, which use CMAKE 3.16.  I've been wanting to transition off AppVeyor and move to GitHub Actions.  I can't remember what the issues were when we last looked into this, and I'm afraid I don't have time to tackle that at the moment.
Another minor challenge is that we've been doing a lot of CUDA (and HIP) work on the staging branch (which has not been pushed to in a while).  This branch consolidates work from multiple branches, including new variable-rate (de)compression work and HIP support.  Once complete, we will merge all this new work into develop.
I would prefer to incorporate these changes there first and work out any potential kinks before merging into develop.  Currently our only GPU tests are being run at LLNL through GitLab CI, and so we'll also need to see if there are any issues there before I'm ready to merge into develop.
If you don't mind, can you please retarget your PR to the staging branch?  I expect it will be another couple of months or so before we will complete work on staging and will be ready to merge into develop.

@robertu94 A quick update: This PR conflicts with other changes we've recently made on the staging branch.  Some of your proposed changes have, however, been adopted in the latest commits on that branch, which also address #178.  This essentially required bumping CMake to 3.23, but only when ZFP_WITH_CUDA is enabled--otherwise we stick with CMake 3.9.  Please reopen if these changes do not address your needs.


Remove server and shared sprite component

Requires space-wizards/RobustToolbox/pull/3981

visualizer gaming

This broke the map renderer


arch aur build broken

The build have success but launching give
Theme dir:  QDir( "/home/vista/.cache/yay/gittyup/src/build/Resources" , nameFilters = { "" },  QDir::SortFlags( Name | IgnoreCase ) , QDir::Filters( Dirs|Files|Drives|AllEntries ) )
Theme dir:  QDir( "/home/vista/.cache/yay/gittyup/src/build/Resources" , nameFilters = { "" },  QDir::SortFlags( Name | IgnoreCase ) , QDir::Filters( Dirs|Files|Drives|AllEntries ) )
PANIC: unprotected error in call to Lua API (cannot open /home/user/.cache/yay/gittyup/src/build/Resources/System.lua: No such file or directory)
[1]    305022 IOT instruction (core dumped)  gittyup
Please see comments on AUR page

I'm the author of the AUR package, but the real problem is upstream and already know. In fact the author was working on a fix, but it hasn't gotten merged yet.
See #191.

Closing as duplicate of #217


[BUG] Hubs do not always appear as HomeKit TVs in the Apple TV Remote app

Describe the bug
I have 3 Harmony hubs connected.  They all display in HomeKit and work perfectly.  But in the Apple TV Remote in Control Center, they are very inconsistent.  Sometimes one shows up.  Sometimes they all show up.  Sometimes none of them are there.
To Reproduce
Hard to reproduce as there does not seem to be any common scenarios that produce it.  But I suspect it only happens when you have multiple Harmony hubs.
Expected behavior
All connected Harmony hubs should show up in the Apple TV Remote in Control Center.
Screenshots
In the screenshot, you can see that only one Harmony hub (Loft TV) is being picked up.

IOS (please complete the following information):

Version: 13.4.1
Device: iPhone 11 Pro Max

Logs
No errors appear in logs
Config
      {
           "platform": "HarmonyHubWebSocket",
           "name": "FamilyRoomHarmonyHub",
           "hubIP": "xxx.xxx.x.xxx",
           "mainActivity": "Watch Apple TV",
           "otherPlatforms": [
               {
                   "name": "LoftHarmonyHub",
                   "hubIP": "xxx.xxx.x.xxx",
                   "mainActivity": "Watch Loft Apple TV"
               },
               {
                   "name": "MasterBedroomHarmonyHub",
                   "hubIP": "xxx.xxx.x.xxx",
                   "mainActivity": "Watch Master Bedroom Apple TV",
                   "homeControlsToPublishAsAccessoriesSwitch": [
                       "hue-switch.harmony_master_bedroom_fan_switch",
                       "hue-switch.harmony_master_bedroom_fan_light_switch"
                   ]
               }
           ]
       },

Additional context
Add any other context about the problem here.

Hi, I think it was introduced in latest homebridge but not sure, still checking this. logs in full (DEBUG=*) while this is happening could help . Referenced also in #261 I think.

Here is the log.  Please let me know if this is useful.  Thanks!
Log.txt

Did not find any usefull info in there. Was the problem occuring in this log ? it seems only to be a startup log

Only one of the 3 hubs was showing up at the time that I grabbed the logs.  In fact, I think I have only seen the Loft hub exclusively for quite some time now.  Is there a limitation that only allows one hub into the remote app?

The fact to  publish them as external accessories was for that purpose . I think it is homebridge / hap related but not sure ... could you try removing one and adding again ?

Can you try with homebridge 1.0.4 ? Other users seems to say it is working again

I am actually on 1.0.4.  One more thought, based on your comment regarding external accessories.  Do I need to include:
"publishAllTVAsExternalAccessory" : true
I am not currently doing that in my config.  Maybe that was added after I created it, or maybe I missed it?

OK, so it is not publishAllTVAsExternalAccessory. I tried that and it did nothing.  So then I tried removing all TVs, and then adding back only the main one I need in the remote widget (Family Room TV).  It did show up then.  Then I added back the other two hubs.  Still, only the Family Room TV shows up in the remote widget.  I did notice this in the logs:

TV accessory added in your bridge, if another plugin is exposing a TV accessory this one might not be visible in your remote widget

I don't have another plugin exposing them to HomeKit thought Homebridge.  But it sort of sounds like this might be close to the issue.  Thoughts?

Then I added back the other two hubs.
Did you remove the whole hub ? From your config, the frist TV was linked to the hub, only second and third had to be removed individually (force touch on the accessory in home app)

Then I added back the other two hubs.

Are they visible inside home app ? Did you add the 2nd and 3rd manually ? The log you are seeing is a reminder for external accessories : they are not linked directly to the hub exposed by homekit, and have to be added like any other device in home app (with the same code / by autodiscovery)

Sorry, I should have given more detail.  First I completely removed HarmonyHubWebSocket from my config and then restarted Homebridge.  This of course removed it from HomeKit.  I also verified that there were no remaining references in cachedAccessories.
I then added HarmonyHubWebSocket back, with only one hub (Family Room).  I restarted, and this hub showed up in HomeKit and in the remote widget.
I then added back the other two hubs.  I restarted, and added them in to HomeKit.  All 3 now show up and work in HomeKit.  But only the Family Room hub shows up in the remote widget.

I think your external accessories are messed up i you did not have to re add them one by one in home app.
They are not cached, only referenced in persists folder, and Is suspect you have to delete them and R-eadd them from home app

That sounds plausible.  Do you have a recommendation how to fix it?
Worst case, the primary TV that I want to be able to control in the remote widget IS there now.  So it is not the end of the world if I can't get the other two TVs to show up.  But it would be nice to have them there.

I discussed with @supereg about this on discord, and here is what he is saying :

would you mind just reinstalling 1.0.4 to ensure you got the latest version and that all the latest depedencies are pulled in (some dependencies got updated after the release of 1.0.4 with minor changes which get pulled in automatically with reinstalling).
Would` be great if you could report back on this, if the issue still persists when running the current, latest versions of everything. There were some changes over the last few versions regarding the underlying dns-sd implementation."

And

the latest 1.0.4 should replicate behavior like it was at 0.4.x
We currently are also in the process of creating a new dns-sd aka bonjour implementation. It improves heavily on bonjour-hap and we hope we can squash a lot of issues users are currently having. But that will still take some time to release.

So let me know if possible !

Thanks for the info.  I downloaded the latest docker image today, but unfortunately it is still the same result.  Like I said, it is not the end of the world.  I have the main TV that I want in the remote widget.  The others are just nice to have.

Check out this HomeAssistant thread.  It looks like this might actually be a limitation in HomeKit.
https://community.home-assistant.io/t/homekit-new-options-tv-source/98912/84?u=_mike

Check out this HomeAssistant thread. It looks like this might actually be a limitation in HomeKit.
https://community.home-assistant.io/t/homekit-new-options-tv-source/98912/84

Hi, this is why the second one or all can be exposed as external accessories . It was working fine but it seems that latest homebridge has some problems with that .

@donavanbecker could you help us on this and especially what to check with homebridge team ?

i am having simila issue but for me the second hub is not coming as a remote but in homekit everything is working fine

@joerexlo : did you publish as external accessories all of your remotes ? IT seems more reliable this way.

Thanks @nicoduj  I tried this and it worked. published as external and then added them manually.


Reflect 5.5.2 release in pom files

Follow up of e7b39e506140f6e7358dbd7f9a4aed729777ab7a and c897793043a7a76d41405c00dd750227723b1923.

retest this please

retest this please


Added new geo tagger script

The previous script 'geotagging.py' to add GPS data to images only worked for CAM triggers. This script will tag any set of arbitrary JPG images that have a correct local time on their creation date. Very useful when tagging a batch of photos taken from a GoPro on time lapse mode after sync the time with a computer/smartphone.
It also can generate a KML file to show the GPS and altitude of the tagged images on Google Maps.

Thanks, this is useful! rebased & applied.
Just a heads-up, we're planning to switch to a new logger with different file format. A python parsing library is under https://github.com/PX4/pyulog


Carthage support

Hi,
For macOS projets it's will be great to make your component Carthage compatible
Take a look at these articles:

Ruthlessly Simple Dependency Management with Carthage
Carthage Tutorial: Getting Started
Making Carthage-compatible Frameworks with Swift
Swift Cross Platform Framework (section Configure targets for Carthage) 👍

On your README.md add   on top and add section for the installation with Carthage.

It already supports Carthage: https://github.com/sindresorhus/Preferences#carthage


fixed gradle copy font tasks when using variants

Fixes #959
Solution in PR 913 was correct, just needed to reapply changes / fix merge conflicts.

Thanks!


1433821999:AAFuA2qYvVR7NVzIxEB6JzFHABOkG-9ALzE

Hii what is this

If you have general questions about the Bot API, kindly contact @BotSupport.

If you have general questions about the Bot API, kindly contact @BotSupport.


Trying to get property 'user' of non-object

I'm facing an issue when i'm trying to pass ticket id which does not exist in below code. Code belongs to src/Models/Agent.php
/**
     * Check if user is the owner for a ticket.
     *
     * @param int $id ticket id
     *
     * @return bool
     */
    public static function isTicketOwner($id)
    {
        if (auth()->check()) {
            if (auth()->user()->id == Ticket::find($id)->user->id) {
                return true;
            }
        }
    }

If we update that code as below then that bug will be resolved. I request you to update code or solve that bug.
/**
     * Check if user is the owner for a ticket.
     *
     * @param int $id ticket id
     *
     * @return bool
     */
    public static function isTicketOwner($id)
    {
    if (Ticket::find($id)) {
        if (auth()->check()) {
            if (auth()->user()->id == Ticket::find($id)->user->id) {
                return true;
            }
        }
    }
    return false;
}

Fixed in 6b8f6fe


DomainAwareDataset str repr edge case handling

Issue #12

Handling the str output of a DomainAwareDataset if the number of domin_names_ is too large
Print the number of datapoints in the dataset

The goal is to have a similar string representation as torchvision for datasets:
Dataset CIFAR10     Number of datapoints: 50000     Root location: datasets/CIFAR10     Split: Train
However rn in the DomainAwareDataset object we don't have the Dataset name + Root location

@YanisLalou Flake8 is not happy here as well.


safe.Checks + jobpool

Pull Request Test Coverage Report for Build<PHONE_NUMBER>6
Details

0 of 67 (0.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-1.1%) to 65.491%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

safe/checks.go
0
29
0.0%

jobpool/jobpool.go
0
38
0.0%

Totals

Change from base Build<PHONE_NUMBER>4:
-1.1%

Covered Lines:
2636

Relevant Lines:
4025

💛  - Coveralls