SegFault in REQUIRE() when compiled by MSVC for x86 in Release mode

[arobenko]

Recently I decided to migrate my projects from using cxxtext to catch2, mostly because the former hasn't been updated / maintained for a while and latest MSVC2019 compiler start reporting various warnings inside.

The conversion is pretty simple with replacement of TS_ASSRT() with REQUIRE() macro and test function replaced with TEST_CASE(). However, when compiled with MSVC for 32bit (x86) architecture in release mode (-DCMAKE_BUILD_TYPE=Release) SegFault is reported in some cases.

For example I have the code with 3 sequential REQUIRE() statements, each and every one is working fine (when others are commented out), but if there are two or more one of them causes the fault. The failure is consistent with all the VS2015, VS2017, and VS2019 compilers. Note, that the same comparisons with TS_ASSERT() macro worked fine with cxxtext. Looks like the optimizations are too aggressive and work incorrectly for the catch2 code.

I've also noticed that your appveyor configuration doesn't test Win32 in Release mode. Is it on purpose? Is the reported problem a known issue? Have you tried to debug it and/or report to Microsoft?

Thanks

[KubaO]

One thing that catches people is that each test scenario is a trace, and they are all independent. So, basically, whatever's inside of a section like SCENARIO, WHEN, THEN, etc. is invisible to corresponding sections at the same level. E.g.

SCENARIO("s1") {
  /* do t1 */
  GIVEN("g1") {
    /* do h1 */
    REQUIRE("r1");
  }
  GIVEN("g2") {
    /* do h2 */
    REQUIRE("r2"):
  }
}

When h2 and r2 run, the effects of h1 and r1 should be invisible, but t1 is visible. Instead of comments you can set up variable values and see them in the debugger at the time of the crash. Furthermore, it's on you to debug it :) IOW, you have to do a relase-with-debug-info build and get down to the basics and figure it out, I'm afraid. It's highly probable that the failure is in your own code. I run it on 32 bits no problem. Make sure you updated your compiler to the newest version!

[Mode-77]

I believe I was able to recreate this and will try to come up with a minimal reproducible example. In my case, it seemed to be related to the harsh optimizations the compiler was doing. I disabled function-level linking (/Gy), and the exceptions disappeared.

/Gy (function-level linking)

[Mode-77]

Circling back to this-- I have come across this again. Deleting the object files and rebuilding seems to have fixed it for me.