New unexpected build failures on 20240603.1.0 #10004

llvm-beanz · 2024-06-06T16:10:02Z

past-due · 2024-06-06T16:56:47Z

We are also seeing new issues in the 20240603.1.0 Windows Server 2022 image, on GitHub Actions - Standard Runners.

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.

Esvandiary · 2024-06-06T16:56:57Z

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. We're building a C++ project using CMake and VS2022.

In our case, the build process itself succeeds but trying to run any of the resulting executables later in the workflow fails with Access violation. Local builds of the same code do not exhibit any issues.

ScottTodd · 2024-06-06T17:10:58Z

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.

past-due · 2024-06-06T17:53:05Z

The issue may be due to a combination of the ordering of the PATH environment variable, older versions of vcruntime in the path (ex. 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. constexpr mutex constructor microsoft/STL#3824 > - Make the constexpr mutex constructor opt-in microsoft/STL#4000 Revert "Make the constexpr mutex constructor opt-in (#4000)" microsoft/STL#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.

firthm01 · 2024-06-06T19:14:03Z

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.```

Esvandiary · 2024-06-06T19:15:17Z

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, which wouldn't conflict.

rouault · 2024-06-06T19:26:04Z

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)

mkruskal-google · 2024-06-06T19:57:06Z

We hit this too and traced it back to std::mutex usage in https://github.com/abseil/abseil-cpp. 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.

We also only see this in optimized builds. Our debug-built executables still work.

The stacktrace we got:

*** SIGSEGV received at time=1717698962 ***
[1920](https://github.com/protocolbuffers/protobuf/actions/runs/9406060503/job/25908647666?pr=17050#step:3:1946)
@ 00007FF638B1F1D2 (unknown) `__scrt_common_main_seh'::`1'::filt$0
[1921](https://github.com/protocolbuffers/protobuf/actions/runs/9406060503/job/25908647666?pr=17050#step:3:1947)
@ 00007FF9C733EFF0 (unknown) _C_specific_handler
[1922](https://github.com/protocolbuffers/protobuf/actions/runs/9406060503/job/25908647666?pr=17050#step:3:1948)
@ 00007FF9D5A843BF (unknown) _chkstk
[1923](https://github.com/protocolbuffers/protobuf/actions/runs/9406060503/job/25908647666?pr=17050#step:3:1949)
@ 00007FF9D5A1186E (unknown) RtlVirtualUnwind2
[1924](https://github.com/protocolbuffers/protobuf/actions/runs/9406060503/job/25908647666?pr=17050#step:3:1950)
@ 00007FF9D5A833AE (unknown) KiUserExceptionDispatcher
[1925](https://github.com/protocolbuffers/protobuf/actions/runs/9406060503/job/25908647666?pr=17050#step:3:1951)
@ 00007FF9C72B3278 (unknown) Thrd_yield
[1926](https://github.com/protocolbuffers/protobuf/actions/runs/9406060503/job/25908647666?pr=17050#step:3:1952)
@ 00007FF638B13566 (unknown) absl::lts_20240116::time_internal::cctz::time_zone::Impl::LoadTimeZone
[1927](https://github.com/protocolbuffers/protobuf/actions/runs/9406060503/job/25908647666?pr=17050#step:3:1953)
@ 00007FF638B1245F (unknown) absl::lts_20240116::time_internal::cctz::local_time_zone
[1928](https://github.com/protocolbuffers/protobuf/actions/runs/9406060503/job/25908647666?pr=17050#step:3:1954)
@ 00007FF638B1184E (unknown) absl::lts_20240116::InitializeLog

henryruhs · 2024-06-06T20:25:04Z

My Python code using ctypes.windll.kernel32.GetShortPathName to shorten paths stopped working since this runner Image: windows-2022 and Version: 20240603.1.0 update.

🟢 20240514.3.0: https://github.com/facefusion/facefusion/actions/runs/9401500581/job/25893418056
🔴 20240603.1: https://github.com/facefusion/facefusion/actions/runs/9407074170/job/25912005903

bduffany · 2024-06-06T20:48:19Z

20240603.1.0 broke us too; we're consistently seeing nondescript "failed to execute command" errors in some protoc.exe executions (google protobuf compiler).

rouault · 2024-06-06T21:35:06Z

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 : rouault/gdal@c4ab31f . My builds work fine with that workaround.

…atest 20240603.1.0 Cf actions/runner-images#10004 Other approach attempted in 9ff56b3 didn't result in finding a recent enough vcruntime140.dll

…atest 20240603.1.0 Cf actions/runner-images#10004 Other approach attempted in rouault@9ff56b3 didn't result in finding a recent enough vcruntime140.dll

ScottTodd · 2024-06-06T22:59:39Z

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?

randombit · 2024-06-07T00:22:41Z

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 3221225477

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.

Visual C++ devs (Microsoft) did something idiotic, and made it so that if code compiled with the latest compiler runs against an older runtime it ... crashes without any message. https://developercommunity.visualstudio.com/t/Access-violation-in-_Thrd_yield-after-up/10664660#T-N10668856 Then Github (Microsoft) shipped an image with a new compiler and an old runtime, so that compiling anything and trying to run it fails actions/runner-images#10004 Truly extraordinary

YOU54F · 2024-06-07T01:20:25Z

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

curl --output foo --write-out "%{http_code}" --location https://github.com/pact-foundation/pact-ruby-standalone/releases/download/v2.4.4/pact-2.4.4-windows-x86_64.zip
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: libcurl function was given a bad argument
000

I believe my error is curl/curl#13845 probably due to the image update, updating curl deps

According to actions/runner-images#10004, the problems with the Windows runners have been fixed. They prevented successful runs for release builds. So this commit reverts 20c1fd8.

BrianMouncer · 2024-06-22T23:10:00Z

@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?

BrianMouncer · 2024-06-22T23:18:45Z

@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. We poured through every commit and reran everything piece by piece. 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, rather than just resloving this GH Issue because one persons builds are passing while dozens others are still broken...

MarkCallow · 2024-06-23T05:04:35Z

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

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

MarkCallow · 2024-06-23T05:15:53Z

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.

mprather · 2024-06-23T21:11:33Z

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).

MarkCallow · 2024-06-27T06:14:22Z

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

MarkCallow · 2024-06-27T06:30:53Z

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 job. It suffered crashes and SEH exceptions in the way familar to everyone here. The workaround is needed also with ClangCL.

Instead of removing the older version of the vcruntime from the Temurin JVM installation in the GitHub Actions runner image, define `_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR` when compiling libktx and ${ASTCENC_LIB_TARGET}. This makes the code compatible with older VC runtimes removing the burden from users to ensure their JVM installation uses the latest VC runtime. See actions/runner-images#10055. For further background see actions/runner-images#10004 and https://developercommunity.visualstudio.com/t/Access-violation-in-_Thrd_yield-after-up/10664660#T-N10669129-N10678728. Includes 2 other minor changes: 1. Move the compiler info dump in `CMakeLists.txt` to before first use of the compiler info and recode it to use `cmake_print_variables`. 2. Disable dump of system and platform info in `tests/loadtests/CMakeLists.txt`.

This reverts commit 205f163.

This PR contains two changes: 1) Moves a pragma to disable a warning, which seems to be required by the new compiler. 2) Adds a preprocessor define to workaround the crashes caused by the runner image mismatching C++ runtime versions. The second change we will want to revert once the runner images are fixed. The issue tracking the runner images is: actions/runner-images#10004 Related microsoft#6668 (cherry picked from commit 0b9acdb)

This removes the hack introduced in microsoft#6683 to workaround issues in the GitHub and ADO runner image: actions/runner-images#10004 Rumor has it the runner images are now fixed... let's see. Fixes microsoft#6674 (cherry picked from commit 98bb80a)

…ex::lock (_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR) if (WIN32 AND IMGUI_BUNDLE_BUILD_PYTHON) # Windows: workaround against msvc Runtime incompatibilities when using std::mutex::lock # Early 2024, msvcp140.dll was updated, and Python 3.11/3.12 are shipped with their own older version of msvcp140.dll # As a consequence the python library will happily crash at customer site, not bothering to mention # the fact that the loaded version of msvcp140.dll is incompatible... # See: # https://developercommunity.visualstudio.com/t/Access-violation-in-_Thrd_yield-after-up/10664660 # actions/runner-images#10004 # #239 (comment) add_compile_definitions(_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR) endif()

…failures (#1611) The new GH runner release [20240603.1](https://github.com/actions/runner-images/releases/tag/win22%2F20240603.1) requires minimum 14.40 for MSVC toolset. Set [VS2022 BuildTools to 17.9.7](actions/runner-images#10004 (comment)) as version 17.10 is busted with several dependencies. #### What does this implement or fix? #### Any other comments? #### Checklist <details> <summary> Checklist for code changes... </summary> - [ ] Have you updated the relevant docstrings, documentation and copyright notice? - [ ] Is this contribution tested against [all ArcticDB's features](../docs/mkdocs/docs/technical/contributing.md)? - [ ] Do all exceptions introduced raise appropriate [error messages](https://docs.arcticdb.io/error_messages/)? - [ ] Are API changes highlighted in the PR description? - [ ] Is the PR labelled as enhancement or bug so it appears in autogenerated release notes? </details>

llvm-beanz added bug report needs triage labels Jun 6, 2024

llvm-beanz mentioned this issue Jun 6, 2024

VS2022 bots are failing, spuriously? microsoft/DirectXShaderCompiler#6674

Closed

tgerla mentioned this issue Jun 6, 2024

Action has stopped working, fails to download syft anchore/sbom-action#472

Closed

rouault mentioned this issue Jun 6, 2024

CI: workaround issue with too old vcruntime140.dll on image windows-latest 20240603.1.0 OSGeo/gdal#10152

Merged

ScottTodd mentioned this issue Jun 6, 2024

Skip tests failing on latest GitHub Actions runner image. iree-org/iree#17595

Merged

randombit mentioned this issue Jun 7, 2024

MSVC 19.40 miscompilation/crash randombit/botan#4103

Closed

randombit mentioned this issue Jun 7, 2024

Add a workaround for MSVC/GH fuckup randombit/botan#4105

Merged

isaacbrodsky mentioned this issue Jun 7, 2024

use Files.createTempFile uber/h3-java#141

Merged

ijunaidm added CI windows-2022 and removed needs triage labels Jun 7, 2024

ijunaidm assigned ijunaidm and kishorekumar-anchala Jun 7, 2024

sophimao added a commit to sophimao/fpga-runtime-for-opencl that referenced this issue Jun 21, 2024

Remove workaround added for actions/runner-images#10004

3906151

sophimao added a commit to intel/fpga-runtime-for-opencl that referenced this issue Jun 25, 2024

Remove workaround added for actions/runner-images#10004

b30a134

MarkCallow mentioned this issue Jun 27, 2024

Change MSVC std::mutex workaround KhronosGroup/KTX-Software#923

Merged

lelegard mentioned this issue Jun 27, 2024

Errors compiling on Windows with VS 2022 17.6 LTSC tsduck/tsduck#1476

Closed

tt4g mentioned this issue Jun 30, 2024

Crash on Windows x64 in spdlog_ex constructor gabime/spdlog#2902

Closed

ptheywood mentioned this issue Jul 9, 2024

Windows CI failures FLAMEGPU/FLAMEGPU2#1211

Closed

tt4g mentioned this issue Jul 9, 2024

Logger in Unmanaged DLL called by C# DLL crashes Oracle Simphony gabime/spdlog#3119

Closed

Airyzz mentioned this issue Jul 12, 2024

Windows release only working with debug .dll files media-kit/media-kit#892

Closed

obrix mentioned this issue Jul 12, 2024

Fix MSVC runtime binaries incompatibility issues powsybl/pypowsybl#803

Merged

7 tasks

vyazelenko added a commit to real-logic/aeron that referenced this issue Jul 15, 2024

Revert "[CMake] Attempt workaround for actions/runner-images#10004."

cb851ac

This reverts commit 205f163.

lassoan mentioned this issue Jul 15, 2024

CLI executable terminates with fault due to incompatible system C++ redistributable Slicer/Slicer#7847

Open

StephanTLavavej mentioned this issue Aug 1, 2024

Revert _DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR workaround thorvg/thorvg#2611

Merged

pthom mentioned this issue Aug 3, 2024

Portable File Dialogs not working on Windows in v1.5.2 but did work in v1.3, v1.52 does work on MacOS pthom/imgui_bundle#239

Closed

Hind-M mentioned this issue Aug 8, 2024

[win-64] Remove workaround mamba-org/mamba#3398

Merged

je5442804 mentioned this issue Aug 20, 2024

777.18 build crash backengineering/llvm-msvc#107

Closed

cwaldren-ld mentioned this issue Sep 9, 2024

Access violation issue while creating LDClientSDK client using LDClientSDK_New launchdarkly/cpp-sdks#434

Closed

MikePopoloski mentioned this issue Oct 20, 2024

Unknown error MikePopoloski/pyslang#354

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

New unexpected build failures on 20240603.1.0 #10004

New unexpected build failures on 20240603.1.0 #10004

llvm-beanz commented Jun 6, 2024

past-due commented Jun 6, 2024 •

edited

Loading

Esvandiary commented Jun 6, 2024 •

edited

Loading

ScottTodd commented Jun 6, 2024

past-due commented Jun 6, 2024 •

edited

Loading

firthm01 commented Jun 6, 2024

Esvandiary commented Jun 6, 2024 •

edited

Loading

rouault commented Jun 6, 2024

mkruskal-google commented Jun 6, 2024 •

edited

Loading

henryruhs commented Jun 6, 2024 •

edited

Loading

bduffany commented Jun 6, 2024 •

edited

Loading

rouault commented Jun 6, 2024

ScottTodd commented Jun 6, 2024

randombit commented Jun 7, 2024

YOU54F commented Jun 7, 2024 •

edited

Loading

BrianMouncer commented Jun 22, 2024

BrianMouncer commented Jun 22, 2024 •

edited

Loading

MarkCallow commented Jun 23, 2024

MarkCallow commented Jun 23, 2024

mprather commented Jun 23, 2024

MarkCallow commented Jun 27, 2024

MarkCallow commented Jun 27, 2024 •

edited

Loading

New unexpected build failures on 20240603.1.0 #10004

New unexpected build failures on 20240603.1.0 #10004

Comments

llvm-beanz commented Jun 6, 2024

Description

Platforms affected

Runner images affected

Image version and build link

Is it regression?

Expected behavior

Actual behavior

Repro steps

past-due commented Jun 6, 2024 • edited Loading

Esvandiary commented Jun 6, 2024 • edited Loading

ScottTodd commented Jun 6, 2024

past-due commented Jun 6, 2024 • edited Loading

firthm01 commented Jun 6, 2024

Esvandiary commented Jun 6, 2024 • edited Loading

rouault commented Jun 6, 2024

mkruskal-google commented Jun 6, 2024 • edited Loading

henryruhs commented Jun 6, 2024 • edited Loading

bduffany commented Jun 6, 2024 • edited Loading

rouault commented Jun 6, 2024

ScottTodd commented Jun 6, 2024

randombit commented Jun 7, 2024

YOU54F commented Jun 7, 2024 • edited Loading

BrianMouncer commented Jun 22, 2024

BrianMouncer commented Jun 22, 2024 • edited Loading

MarkCallow commented Jun 23, 2024

MarkCallow commented Jun 23, 2024

mprather commented Jun 23, 2024

MarkCallow commented Jun 27, 2024

MarkCallow commented Jun 27, 2024 • edited Loading

past-due commented Jun 6, 2024 •

edited

Loading

Esvandiary commented Jun 6, 2024 •

edited

Loading

past-due commented Jun 6, 2024 •

edited

Loading

Esvandiary commented Jun 6, 2024 •

edited

Loading

mkruskal-google commented Jun 6, 2024 •

edited

Loading

henryruhs commented Jun 6, 2024 •

edited

Loading

bduffany commented Jun 6, 2024 •

edited

Loading

YOU54F commented Jun 7, 2024 •

edited

Loading

BrianMouncer commented Jun 22, 2024 •

edited

Loading

MarkCallow commented Jun 27, 2024 •

edited

Loading