Describe the bug
Our Continuous Integration server fail from time to time (not always, about once per 10 builds maybe), and we observe that the vcpkg.exe would silently crash without any error message.
We setup our developer environment to look as much as possible as the CI, and run the build in a loop to catch the issue. We started using ProcDump to capture a callstack when the crash occurs. After many days of attempts, we finally got a valid crash dump.
Environment
- OS: Observed on Windows Server 2019.
- Compiler: Visual Studio Build Tools 16.8.5.
To Reproduce
Steps to reproduce the behavior:
Our project is a (large) private CMake project with many libraries, and a few executables, and the VCPKG dependencies total 135 packages to compile (to be honest, boost accounts for nearly half of them). We are using overlays since some dependencies are private repos.
- Define the following environment variables:
-- VCPKG_DISABLE_METRICS=true
-- VCPKG_FEATURE_FLAGS=manifests,registries,versions
-- VCPKG_USE_NUGET_CACHE=true
-- VCPKG_DEFAULT_TRIPLET=x64-windows
- run
cmake -G Ninja <source_directory>
inside our main CMakeLists.txt, there is the line
set(CMAKE_TOOLCHAIN_FILE "$ENV{VCPKG_ROOT}/scripts/buildsystems/vcpkg.cmake" CACHE STRING "")
The crash occurs during the vcpkg install phase, within the first 3 seconds; that's when it is computing the dependency graph.
Expected behavior
No crash. Or if there is an unexpected error, write a meaningful message to stderr or stdout.
Failure logs
The zip file (dump, exe and pdb) is 28MB, so it is too large to upload here.
So I made it available here as a "release" on a dummy repo.
Additional context
I tried to analyze the dump myself before opening this issue, because I suspected something wrong on our setup. The crash happens during the constructor of a PackageSpec, when trying to copy a string. It doesn't look like an out-of-memory issue, rather that the vector tried to allocate in-place while it was already full, instead of re-allocating to make more space.
I hope you understand better than I what is going on, because I'm not fully understanding how it got there.
Describe the bug
Our Continuous Integration server fail from time to time (not always, about once per 10 builds maybe), and we observe that the vcpkg.exe would silently crash without any error message.
We setup our developer environment to look as much as possible as the CI, and run the build in a loop to catch the issue. We started using ProcDump to capture a callstack when the crash occurs. After many days of attempts, we finally got a valid crash dump.
Environment
To Reproduce
Steps to reproduce the behavior:
Our project is a (large) private CMake project with many libraries, and a few executables, and the VCPKG dependencies total 135 packages to compile (to be honest,
boostaccounts for nearly half of them). We are using overlays since some dependencies are private repos.-- VCPKG_DISABLE_METRICS=true
-- VCPKG_FEATURE_FLAGS=manifests,registries,versions
-- VCPKG_USE_NUGET_CACHE=true
-- VCPKG_DEFAULT_TRIPLET=x64-windows
cmake -G Ninja <source_directory>inside our main CMakeLists.txt, there is the line
set(CMAKE_TOOLCHAIN_FILE "$ENV{VCPKG_ROOT}/scripts/buildsystems/vcpkg.cmake" CACHE STRING "")The crash occurs during the
vcpkg installphase, within the first 3 seconds; that's when it is computing the dependency graph.Expected behavior
No crash. Or if there is an unexpected error, write a meaningful message to stderr or stdout.
Failure logs
The zip file (dump, exe and pdb) is 28MB, so it is too large to upload here.
So I made it available here as a "release" on a dummy repo.
Additional context
I tried to analyze the dump myself before opening this issue, because I suspected something wrong on our setup. The crash happens during the constructor of a PackageSpec, when trying to copy a string. It doesn't look like an out-of-memory issue, rather that the vector tried to allocate in-place while it was already full, instead of re-allocating to make more space.
I hope you understand better than I what is going on, because I'm not fully understanding how it got there.