CI Test (gtest) failing on Windows

[pattacini]

Bug description

Today, all of a sudden, CI started reporting failures during testing (using googletest) only on Windows (SHARED_LIBS:OFF).

Here's the generic error:

unknown file: error: SEH exception with code 0xc0000005 thrown in the test body.

Steps to reproduce

See:

• https://github.com/robotology/icub-main/actions/runs/9410612305

Expected behavior

No response

Example repository

No response

Additional context

Thereby, I've looked into the log and found this suggestion:

ERROR: 10 leaked mock objects found at program exit. Expectations on a mock object are verified when the object is destructed. Leaking a mock means that its expectations aren't verified, which is usually a test bug. If you really intend to leak a mock, you can suppress this error using testing::Mock::AllowLeak(mock_object), or you may use a fake or stub instead of a mock.

Then, I've tried to add these lines in the branch fix/windows_unittest:

• master...fix/windows_unittest

Still unsuccessfully. See:

• https://github.com/robotology/icub-main/actions/workflows/ci.yml

cc @Nicogene

[pattacini]

Unittest temporarily disabled on Windows via 629ec2b, on master and devel.

The debug branch fix/windows_unittest has still the gtest enabled.

[pattacini]

The unittest makes use of specific releases of gtest, see:

icub-main/src/unittest/CMakeLists.txt

Line 15 in 629ec2b

GIT_TAG v1.14.0

which didn't change for a while¹ and out of nowhere we started seeing failures since yesterday:

• https://github.com/robotology/icub-main/actions/runs/9410612305

It may be that there's a strange interaction with the CI workspace.

Footnotes

1. Actually, it was https://github.com/google/googletest/tree/release-1.12.0 but I updated it in the attempt to fix the problem, unsuccessfully. However, v1.14.0 is still fairly consolidated, dating back to August 02, 2023. ↩

[traversaro]

I think the relevant change is the compiler (that is provide by GitHub Action image) that changed from to:

2024-06-06T05:51:18.0476112Z --   CMake: 3.29.3 (C:/Program Files/CMake/bin/cmake.exe)
2024-06-06T05:51:18.0478276Z --   C Compiler: MSVC 19.39.33523.0 (C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.39.33519/bin/Hostx64/x64/cl.exe)
2024-06-06T05:51:18.0481096Z --   CXX Compiler: MSVC 19.39.33523.0 (C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.39.33519/bin/Hostx64/x64/cl.exe)

to

2024-06-07T05:26:38.4807555Z --   CMake: 3.29.3 (C:/Program Files/CMake/bin/cmake.exe)
2024-06-07T05:26:38.4809825Z --   C Compiler: MSVC 19.40.33811.0 (C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64/cl.exe)
2024-06-07T05:26:38.4812581Z --   CXX Compiler: MSVC 19.40.33811.0 (C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64/cl.exe)

[traversaro]

Relevant upstream issues:

• MSVC SEH exception with code 0xc0000005 when using SUCCEED google/googletest#4556
• New unexpected build failures on 20240603.1.0 actions/runner-images#10004

[pattacini]

The problem has been solved upstream!
See:

• GitHub Action fixes KhronosGroup/KTX-Software#920 (see CI Test (gtest) failing on Windows #967 (comment) instead).

CI fully restored on master and devel via ab93283.

[MarkCallow]

The problem has been solved upstream! See:
See:

KhronosGroup/KTX-Software#920

CI fully restored on master and devel via ab93283.

I am thoroughly confused as to what a fix in KTX-Software has to do with this repo.

In the interests of accuracy, the referenced PR has nothing to do with fixing the SEH exceptions. The fix for that is the 2024.06.10.1.0 GHA runner image which makes sure C:\Windows\system32 has latest vcruntime140.dll.

The referenced PR fixes a JVM crash when testing the Java binding caused by the JVM continuing to use an old vcruntime140.dll. It also fixes a breakage caused by a change in 2024.06.10 in how GitHub Actions handles setting environment variables from matrix attributes.

[pattacini]

Thanks for pointing this out, @MarkCallow 👍🏻

I've merely jumped to the final comment by @ijunaidm, who was asking the OP if everything was ok with the latest deployment and I mistakenly reported your xref.

The correct PR's fixing the SEH exception should be then:

• add _DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR definition to fix windows build Mause/duckdb-java#6
• add _DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR definition to fix windows build duckdb/duckdb-java#32

[MarkCallow]

The PRs you quote are workarounds for the problem not fixes. A partial fix is the newly deployed 2024.06.10.1.0 runner image. Partial because the JVM still crashes without the workaround in the above PRs. Another issue has been opened for that which contains a pointer to a different workaround that only requires a change to your .yml code not your code. See actions/runner-images#10055.