Googletest: Double free or corruption (fasttop) with google mock

Created on 8 Nov 2016 · 11Comments · Source: google/googletest

I get the following problem when using google mock for a CMake project on Linux.

gmock and gtest are built with CMake. Even without using any google mock features, the error below will occur as long as google mock is linked against my test executable. No problem if linked against google test only.

This occurs after the tests completion. My tests all run good but this segfault occurs right after:

*** Error in `/home/virtualfls/Projects/IMSTK/debug/bin/imstk_geometry_test_driver': double free or corruption (fasttop): 0x00000000007086c0 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7277f)[0x7fffe9eca77f]
/lib64/libc.so.6(+0x78026)[0x7fffe9ed0026]
/lib64/libc.so.6(+0x78d53)[0x7fffe9ed0d53]
/usr/lib64/libstdc++.so.6(_ZNSsD2Ev+0x40)[0x7fffea7ebcb0]
/home/virtualfls/Projects/IMSTK/debug/lib/libgtest.so(_ZN7testing8internal20StringStreamToStringEPSt18basic_stringstreamIcSt11char_traitsIcESaIcEE+0xe0)[0x7ffff7b898a6]
/home/virtualfls/Projects/IMSTK/debug/lib/libgtest.so(_ZNK7testing7Message9GetStringEv+0x2e)[0x7ffff7b85ed2]
/home/virtualfls/Projects/IMSTK/debug/lib/libgtest.so(_ZN7testing8internal18StreamableToStringIiEESsRKT_+0x42)[0x7ffff7ba238d]
/home/virtualfls/Projects/IMSTK/debug/lib/libgtest.so(_ZN7testing8internal18FormatFileLocationEPKci+0x8c)[0x7ffff7b9a0df]
/home/virtualfls/Projects/IMSTK/debug/lib/libgtest.so(_ZN7testing8internal8GTestLogC2ENS0_16GTestLogSeverityEPKci+0x6e)[0x7ffff7b9a378]
/home/virtualfls/Projects/IMSTK/debug/lib/libgmock.so(_ZN7testing8internal11ThreadLocalIPNS_8SequenceEED2Ev+0x54)[0x7ffff76f0b1e]
/lib64/libc.so.6(__cxa_finalize+0x8f)[0x7fffe9e8febf]
/home/virtualfls/Projects/IMSTK/debug/lib/libgmock_main.so(+0x84653)[0x7ffff73b4653]

*** Error in `/home/virtualfls/Projects/IMSTK/debug/bin/imstk_geometry_test_driver': double free or corruption (fasttop): 0x00000000017e9390 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7277f)[0x7fed2dc8177f]
/lib64/libc.so.6(+0x78026)[0x7fed2dc87026]
/lib64/libc.so.6(+0x78d53)[0x7fed2dc87d53]
/usr/lib64/libstdc++.so.6(_ZNSsD2Ev+0x40)[0x7fed2e5a2cb0]
/home/virtualfls/Projects/IMSTK/debug/lib/libgtest.so(_ZSt8_DestroyISsEvPT_+0x18)[0x7fed3b470eb2]
/home/virtualfls/Projects/IMSTK/debug/lib/libgtest.so(_ZNSt12_Destroy_auxILb0EE9__destroyIPSsEEvT_S3_+0x26)[0x7fed3b46e9f3]
/home/virtualfls/Projects/IMSTK/debug/lib/libgtest.so(_ZSt8_DestroyIPSsEvT_S1_+0x23)[0x7fed3b46a764]
/home/virtualfls/Projects/IMSTK/debug/lib/libgtest.so(_ZSt8_DestroyIPSsSsEvT_S1_RSaIT0_E+0x27)[0x7fed3b465891]
/home/virtualfls/Projects/IMSTK/debug/lib/libgtest.so(_ZNSt6vectorISsSaISsEED1Ev+0x35)[0x7fed3b45fbc9]
/lib64/libc.so.6(__cxa_finalize+0x8f)[0x7fed2dc46ebf]
/home/virtualfls/Projects/IMSTK/debug/lib/libgmock.so(+0x84563)[0x7fed3b16b563]

*** Error in `/home/virtualfls/Projects/IMSTK/debug/bin/imstk_geometry_test_driver': double free or corruption (fasttop): 0x00000000022343a0 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7277f)[0x7f484eca977f]
/lib64/libc.so.6(+0x78026)[0x7f484ecaf026]
/lib64/libc.so.6(+0x78d53)[0x7f484ecafd53]
/usr/lib64/libstdc++.so.6(_ZNSsD2Ev+0x40)[0x7f484f7e7cb0]
/lib64/libc.so.6(__cxa_finalize+0x8f)[0x7f484ec6eebf]
/home/virtualfls/Projects/IMSTK/debug/lib/libgmock.so(+0x84563)[0x7f485c193563]

Source

agirault

Most helpful comment

Hi,

I am facing the same issue after upgrading from 1.7.0 to 1.8.0. This happens only when you:

build gtest/gmock with cmake
build gtest/gmock as shared libraries (using -DBUILD_SHARED_LIBS=ON)
in your test binary, you link both gtest AND gtest

The reason is simple: the CMake build of GMock badly embeds the source code from gtest inside gmock.so. When you load both gmock.so and gtest.so in the same address space, then the same global static variable are resolved to the same symbol, but they are initialized twice, and worse, destructed twice. And calling the destructor of things like std::string or std::vector twice clearly leads to double free.

For me the CMakeList.txt of gmock is very wrong. gmock should reference gtest as a real library dependency, not try to embed things like gtest-all.cc in gmock.so. My knowledge of CMake is too low to try to fix it right now. I just know in release 1.7.0 I was using the autotools (ie ./configure) instead of cmake, and there is was working fine. Will try to fallback to autotools again.

Cheers,
Romain

Romain-Geissler-1A on 2 Dec 2017

👍5

All 11 comments

On Windows I get the following compilation errors instead:

3>imstkGeometryTest.obj : error LNK2001: unresolved external symbol "class testing::internal::Mutex testing::internal::g_linked_ptr_mutex" (?g_linked_ptr_mutex@internal@testing@@3VMutex@12@A)
3>imstkGeometryTest.obj : error LNK2001: unresolved external symbol "class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > testing::FLAGS_gtest_filter" (?FLAGS_gtest_filter@testing@@3V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@A)
3>imstkSphereTest.obj : error LNK2001: unresolved external symbol "class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > testing::FLAGS_gtest_filter" (?FLAGS_gtest_filter@testing@@3V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@A)
3>imstkGeometryTest.obj : error LNK2001: unresolved external symbol "class testing::internal::Mutex testing::internal::g_gmock_mutex" (?g_gmock_mutex@internal@testing@@3VMutex@12@A)

can't resolve:

g_gmock_mutex which is at gmock-spec-builders.h#L118
g_linked_ptr_mutex whch is at gtest-linked_ptr.h#L80
'FLAGS_gtest_filter` which is at gtest-port.h#L2514

I'm linking against gtest.lib and gmock.lib

agirault on 8 Nov 2016

👍1

I'm having similar issues. gtest/gmock 1.8.0, gcc 5.4, ubuntu 16.04, cmake 3.6

shavera on 21 Dec 2016

+1. But I get this error only if mock at least one method.

aminought on 31 Dec 2016

I have experienced the same issue on Ubuntu 14.04, g+++ 4.8.4, gmock / gtest 1.7.0.

duong2179 on 4 Jul 2017

I also have those three symbols unresolved when linking to gmock.lib and gtest.lib on Windows, using CMake, with BUILD_SHARED_LIBS=ON. The static version works however.

andschwa on 15 Aug 2017

Will this ever be fixed? Repros on Linux for me too. Pretty much have to hard-code using the static version.

andschwa on 17 Aug 2017

Same problem here (debian linux)! When googletest libs was compiled shared there is always a core dump on exit; donesn't matter if there are tests or not!