Gtest and Gmock - double free or corruption

Question

I've wasted many hours to resolve this problem, but without success. At first, my configuration: Ubuntu 16.04.1, qmake 3.0, cmake 3.5.1, shared gtest and gmock libraries, version 1.8.0. I use Qt Creator, and this is a little example of minimal program that lead to the crush.

main.cpp:

#include <iostream>
#include <gtest/gtest.h>
#include <gmock/gmock.h>

using namespace std;

class A {
    void print() {
        std::cout << "PRINT" << std::endl;
    }
};

class B: public A {
    MOCK_METHOD0(print, void());
};

TEST(MOCK, TEST) {
    B b;
}

int main(int argc, char *argv[])
{
    ::testing::InitGoogleTest(&argc, argv);
    return RUN_ALL_TESTS();
}

google_test.pro:

TEMPLATE = app
CONFIG += console c++11
CONFIG -= app_bundle
CONFIG -= qt

SOURCES += main.cpp

LIBS += -lgtest -lgmock

Tests are OK, but at the end of program I get this error:

* Error in `/home/aminought/QtProjects/build-google_test-Desktop_Qt_5_7_0_GCC_64bit-Debug/google_test': double free or corruption (!prev): 0x0000000001a51270 *

How to fix this error? Very annoying.

Answer 1

This problem occurs only with google test compiled as shared libraries. I don't know why, but simple replacement of shared libraries to static solves the problem.

Answer 2

After some read ups on gtest_discover_tests, it seems that on some platforms the discover of tests cannot be done without knowing the nature of the executable. hence, I had to change the discovery mode on test discovery.

In my case, passing 'DISCOVERY_MODE PRE_TEST' to gtest_discover_tests cmake function fixed the issue.

Answer 3

It's been a few years since this was posted. I could not recreate the exact problem you are having, but recently I have come across the same error message, in a different scenario.

The problem was, that I purposely made an override to TearDown(), freeing a protected member of a fixture class, which resulted in double freeing pointers. It seems that googletest is keeping track of allocated memory and tries to free everything automatically, even though my TearDown() override already did previously. Removing the override solved the problem for me.

I hope it will be useful for someone sometime in the future.

In my case, dynamic linking did not have any effect.