Remove hardcoded v143 toolset from vcpkg triplets and new VLD ignore#352
Draft
Remove hardcoded v143 toolset from vcpkg triplets and new VLD ignore#352
Conversation
All triplets now auto-detect the platform toolset from the current VS installation instead of requiring v143 specifically. This matches the pattern already used by arm64-windows-static-cbt.cmake and allows builds to work on both VS 2022 (v143) and VS 2025 (v145). Also fixes arm64-windows-static-cbt-asan.cmake which inconsistently hardcoded v143 while its non-asan counterpart did not. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Collaborator
Author
|
/azp run Azure-C-Build-Tools-Gate |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Add WahInsertHandleContext and MesBufferHandleReset to the VLD IgnoreFunctionsList. These are Windows OS internal one-time caching allocations (Winsock handle context table entries and RPC computer name cache during DNS resolution) that VLD reports as leaks but are cleaned up by the OS at process exit. This fixes socket_transport_int CTest failures in Debug builds on VS 2025 / Windows Server 2025 pools. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This reverts commit c926a15.
Add WahInsertHandleContext (WS2_32.dll) and MesBufferHandleReset (RPCRT4.dll) to the VLD IgnoreFunctionsList. These are undocumented OS-internal functions chosen deliberately over their public callers (WSASocketW, accept, getaddrinfo, MesEncodeDynBufferHandleCreate) to avoid accidentally masking real application memory leaks. Both functions perform one-time process-lifetime caching allocations that the OS cleans up at exit. They are not called by application code, making them safe and precise suppression targets. Fixes socket_transport_int CTest false failures in Debug builds on VS 2025 / Windows Server 2025 build pools. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Collaborator
Author
|
/azp run Azure-C-Build-Tools-Gate |
|
Azure Pipelines successfully started running 1 pipeline(s). |
The previous VLD fix suppressed WahInsertHandleContext, but the actual leaking function observed in build 156660589 is WahCreateHandleContextTable. This is the function that creates the Winsock helper handle context hash table (2312-byte blocks via GlobalAlloc), called by WSAStartup and WSASocketW/socket. Both functions are now suppressed. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
When multiple GBALLOC_LL_TYPE matrix jobs fail for the same build_configuration + ARCH_TYPE combination (e.g., Debug x64 PASSTHROUGH and Debug x64 JEMALLOC), they both tried to publish 'Debug_x64_artifacts', causing 'artifact already exists' error on the second job. Now includes the allocator type in the name: 'Debug_PASSTHROUGH_x64_artifacts' vs 'Debug_JEMALLOC_x64_artifacts'. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Collaborator
Author
|
/azp run |
|
You have several pipelines (over 10) configured to build pull requests in this repository. Specify which pipelines you would like to run by using /azp run [pipelines] command. You can specify multiple pipelines using a comma separated list. |
Collaborator
Author
|
/azp run Azure-C-Build-Tools-Gate |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Suppress false positive from rasadhlp.dll one-time initialization during DNS resolution. When getaddrinfo is first called, WS2_32.dll dynamically loads rasadhlp.dll via LoadLibraryExA to enumerate namespace providers, which allocates 256-byte blocks that persist for the process lifetime. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
auto-merge was automatically disabled
March 13, 2026 19:37
Pull request was converted to draft
Collaborator
Author
|
/azp run |
|
You have several pipelines (over 10) configured to build pull requests in this repository. Specify which pipelines you would like to run by using /azp run [pipelines] command. You can specify multiple pipelines using a comma separated list. |
Collaborator
Author
|
/azp run Azure-C-Build-Tools-Gate |
|
Azure Pipelines successfully started running 1 pipeline(s). |
WSALookupServiceBeginW is more targeted than getaddrinfo - it is the internal WS2_32 namespace-provider-enumeration entry point that triggers the LoadLibrary of rasadhlp.dll. Using this avoids masking real leaks where application code calls getaddrinfo without a matching freeaddrinfo. The rasadhlp.dll internal functions are unexported and unresolvable without PDBs, so WSALookupServiceBeginW is the most specific named function available in the leak call stack. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add IgnoreModulesList = rasadhlp.dll;dnsapi.dll;mswsock.dll;fwpuclnt.dll to suppress false positives from system DLLs whose internal functions are unexported and cannot be targeted by IgnoreFunctionsList. These DLLs are loaded dynamically during getaddrinfo and allocate memory that persists for the process lifetime. The specific leaking DLLs vary by OS version and installed network providers. WSALookupServiceBeginW is kept in IgnoreFunctionsList as a fallback for older VLD versions that do not support IgnoreModulesList. Requires VLD v2.5.15+ with IgnoreModulesList support (Azure/vld branch anporumb/ignore-modules-list). Older VLD versions silently ignore the new option. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Removed incorrect claims about specific byte sizes per DLL. Documented that RPCRT4.dll and KERNELBASE.dll are the primary leak sources (based on actual callstack analysis), with rasadhlp, dnsapi, mswsock, and fwpuclnt varying by OS version. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
| # VCPKG_PLATFORM_TOOLSET not set - auto-detect from the current VS installation | ||
| # Unfortunately we have to workaround an issue introduced in Visual Studio 17.10 where due to a change in mutex a break in the ABI seems to exist | ||
| # https://github.com/microsoft/STL/releases/tag/vs-2022-17.10 | ||
| # Fixed mutex's constructor to be constexpr. #3824 #4000 #4339 |
Member
There was a problem hiding this comment.
We really have to double check this comment. This caused us to have a hotfix when it happened - I remember that coverage with offload showed some issues but it did get to production, so we should not take it lightly and at least we should ensure that the thing we build with in the gate has the code we want ...
Sorry, it sounds panicky, but at 5k clusters I really don't want to run around patching and retaking stuff if we knew of a potential issue.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
All triplets now auto-detect the platform toolset from the current VS installation instead of requiring v143 specifically. This matches the pattern already used by arm64-windows-static-cbt.cmake and allows builds to work on both VS 2022 (v143) and VS 2025 (v145).
Also fixes arm64-windows-static-cbt-asan.cmake which inconsistently hardcoded v143 while its non-asan counterpart did not.