[Bug]: MSVC - Assertion macro SUCCEED() leeds to a memory leak. about googletest HOT 3 OPEN

I haven't tried this, so I could be wrong, but I think this is probably working as intended.

It looks like under the hood, the SUCCEED() macro allocates memory, and frees it in its destructor. The destructor is not run until after the call to _CrtMemDifference, so I'm guessing this is the source of the difference.

Now we could change SUCCEED() to not allocate memory, but that is not a scalable solution. Any RAII object on the stack is going to have the same problem.

If you really want to use _CrtMemDifference (and I think there are much better memory checkers available, like LSAN), I think you should create an RAII object that saves the state in its constructor and checks for leaks in its destructor. Put this object on the stack and it will ensure that it runs after all objects that were constructed after it have also had their destructors called.

from googletest.

By the way, you can test my hypothesis by simply using an additional set of braces around the body of the test:

TEST(GoogleTest, TestSucceed)
{
    // ---- store heap state ----
    _CrtMemState s1, s2, s3;
    _CrtMemCheckpoint(&s1);

    // ---- TEST ----
    {
        SUCCEED();
    }

    // ---- compare heap state ----
    _CrtMemCheckpoint(&s2);
    bool hasMemoryLeaks = (0 != _CrtMemDifference(&s3, &s1, &s2));
    if (hasMemoryLeaks)
    {
        _CrtMemDumpAllObjectsSince(&s1);
    }
    EXPECT_FALSE(hasMemoryLeaks);
}

from googletest.

@derekmauro Sorry for the delay, I was out of the office for a few days.

Unfortunately, your suggestion does not bring any improvement.

I would have been surprised too, because in my real project the memory leak check is handled in a separate TestEventListener. So the binding scope of SUCCEED() is already finished when the memory check is called. I have simplified the call structure somewhat just for this issue description.

from googletest.