Erreur de segmentation de condition de course lors de l'utilisation de gtest EXPECT_CALL pendant qu'une autre attente utilise la même méthode

Question

J'ai rencontré une erreur de segmentation de condition de concurrence lors de l'utilisation de GTest avec des simulacres et un multithreading. J'utilise GTest 1.8 sur CentOS 6.9, G ++ 6.3.1. Il est possible de déclencher un segfault en appelant EXPECT_CALL sur un mock avec une méthode donnée, tandis qu'un autre thread appelle cette méthode sur le même mock. Voici un exemple minimal:

#include <gmock/gmock.h> 
#include <thread> 
#include <atomic> 

class MyMock 
{ 
public: 
    MOCK_METHOD1(myMethod, void(int n)); 
}; 

TEST(MyClassTest, one) 
{ 
    MyMock mock; 
    std::atomic<int> g_arg(5); 
    bool keepRunning = true; 
    bool isRunning = false; 
    bool canEnd = false; 
    EXPECT_CALL(mock, myMethod(5)) 
    .Times(::testing::AtLeast(1)) 
    .WillRepeatedly(::testing::InvokeWithoutArgs([&isRunning](){ isRunning = true; })); 
    std::thread t1([&mock, &keepRunning, &g_arg]() 
    { 
    while (keepRunning) 
    { 
     mock.myMethod(g_arg.load()); 
    } 
    }); 
    while (!isRunning) {} 
    EXPECT_CALL(mock, myMethod(6)) 
    .Times(::testing::AtLeast(1)) 
    .WillRepeatedly(::testing::InvokeWithoutArgs([&canEnd](){ canEnd = true; })); 
    g_arg.store(6); 
    while (!canEnd) {} 
    keepRunning = false; 
    t1.join(); 
} 

Il peut être compilé avec: g++ -lpthread -lgmock_main -g Gtest_test.cpp -o Gtest_test

Parfois, le problème se produit immédiatement, parfois, vous faites quelques centaines de pistes sans problème. Je dirige comme ceci: gdb --args ./Gtest_test --gtest_repeat=-1 --gtest_break_on_failure

Voici quelques sortie de GDB, lorsque le segfault se produit:

Repeating all tests (iteration 10) . . . 

[==========] Running 1 test from 1 test case. 
[----------] Global test environment set-up. 
[----------] 1 test from MyClassTest 
[ RUN  ] MyClassTest.one 
[New Thread 0x7ffff6d8b700 (LWP 14092)] 

Thread 11 "Gtest_test" received signal SIGSEGV, Segmentation fault. 
[Switching to Thread 0x7ffff6d8b700 (LWP 14092)] 
0x00007ffff7bc8470 in pthread_mutex_lock() from /lib64/libpthread.so.0 
Missing separate debuginfos, use: debuginfo-install libgcc-4.4.7-18.el6.x86_64 libstdc++-4.4.7-18.el6.x86_64 
(gdb) bt 
#0 0x00007ffff7bc8470 in pthread_mutex_lock() from /lib64/libpthread.so.0 
#1 0x0000000000407b5b in testing::internal::MutexBase::Lock (this=0x98) at /usr/include/gtest/internal/gtest-port.h:1928 
#2 0x0000000000407da8 in testing::internal::GTestMutexLock::GTestMutexLock (this=0x7ffff6d8a540, mutex=0x98) at /usr/include/gtest/internal/gtest-port.h:1999 
#3 0x00007ffff7979628 in testing::internal::ExpectationBase::CheckActionCountIfNotDone() const() from /usr/lib64/libgmock_main.so 
#4 0x000000000040ce9c in testing::internal::TypedExpectation<void (int)>::ShouldHandleArguments(std::tuple<int> const&) const (this=0x0, args=std::tuple containing = {...}) at /usr/include/gmock/gmock-spec-builders.h:1100 
#5 0x000000000040c91a in testing::internal::FunctionMockerBase<void (int)>::FindMatchingExpectationLocked(std::tuple<int> const&) const (this=0x7fffffffd850, args=std::tuple containing = {...}) 
    at /usr/include/gmock/gmock-spec-builders.h:1723 
#6 0x000000000040c569 in testing::internal::FunctionMockerBase<void (int)>::UntypedFindMatchingExpectation(void const*, void const**, bool*, std::ostream*, std::ostream*) (this=0x7fffffffd850, untyped_args=0x7ffff6d8ad90, 
    untyped_action=0x7ffff6d8a7e8, is_excessive=0x7ffff6d8ac4f, what=0x7ffff6d8aae0, why=0x7ffff6d8a970) at /usr/include/gmock/gmock-spec-builders.h:1687 
#7 0x00007ffff797a212 in testing::internal::UntypedFunctionMockerBase::UntypedInvokeWith(void const*)() from /usr/lib64/libgmock_main.so 
#8 0x00000000004096cd in testing::internal::FunctionMockerBase<void (int)>::InvokeWith(std::tuple<int> const&) (this=0x7fffffffd850, args=std::tuple containing = {...}) at /usr/include/gmock/gmock-spec-builders.h:1585 
#9 0x0000000000408ba1 in testing::internal::FunctionMocker<void (int)>::Invoke(int) (this=0x7fffffffd850, a1=5) at /usr/include/gmock/gmock-generated-function-mockers.h:101 
#10 0x00000000004087a8 in MyMock::myMethod (this=0x7fffffffd850, gmock_a1=5) at Gtest_test.cpp:11 
#11 0x0000000000406e25 in MyClassTest_one_Test::<lambda()>::operator()(void) const (__closure=0x618d48) at Gtest_test.cpp:28 
#12 0x0000000000407a86 in std::_Bind_simple<MyClassTest_one_Test::TestBody()::<lambda()>()>::_M_invoke<>(std::_Index_tuple<>) (this=0x618d48) at /opt/rh/devtoolset-6/root/usr/include/c++/6.3.1/functional:1391 
#13 0x00000000004079e7 in std::_Bind_simple<MyClassTest_one_Test::TestBody()::<lambda()>()>::operator()(void) (this=0x618d48) at /opt/rh/devtoolset-6/root/usr/include/c++/6.3.1/functional:1380 
#14 0x0000000000407972 in std::thread::_State_impl<std::_Bind_simple<MyClassTest_one_Test::TestBody()::<lambda()>()> >::_M_run(void) (this=0x618d40) at /opt/rh/devtoolset-6/root/usr/include/c++/6.3.1/thread:197 
#15 0x000000000040e33f in execute_native_thread_routine() 
#16 0x00007ffff7bc6aa1 in start_thread() from /lib64/libpthread.so.0 
#17 0x00007ffff6e74bcd in clone() from /lib64/libc.so.6 
(gdb) info threads 
    Id Target Id   Frame 
    1 Thread 0x7ffff7fdc720 (LWP 14079) "Gtest_test" MyClassTest_one_Test::TestBody (this=0x618510) at Gtest_test.cpp:36 
* 11 Thread 0x7ffff6d8b700 (LWP 14092) "Gtest_test" 0x00007ffff7bc8470 in pthread_mutex_lock() from /lib64/libpthread.so.0 
(gdb) t 1 
[Switching to thread 1 (Thread 0x7ffff7fdc720 (LWP 14079))] 
#0 MyClassTest_one_Test::TestBody (this=0x618510) at Gtest_test.cpp:36 
36 while (!canEnd) {} 
(gdb) bt 
#0 MyClassTest_one_Test::TestBody (this=0x618510) at Gtest_test.cpp:36 
#1 0x00007ffff7968edf in void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*)() from /usr/lib64/libgmock_main.so 
#2 0x00007ffff7962cd4 in void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*)() from /usr/lib64/libgmock_main.so 
#3 0x00007ffff7947a7c in testing::Test::Run()() from /usr/lib64/libgmock_main.so 
#4 0x00007ffff7948326 in testing::TestInfo::Run()() from /usr/lib64/libgmock_main.so 
#5 0x00007ffff79489ff in testing::TestCase::Run()() from /usr/lib64/libgmock_main.so 
#6 0x00007ffff794f5c9 in testing::internal::UnitTestImpl::RunAllTests()() from /usr/lib64/libgmock_main.so 
#7 0x00007ffff796a2f2 in bool testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*)() 
    from /usr/lib64/libgmock_main.so 
#8 0x00007ffff7963a48 in bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*)() 
    from /usr/lib64/libgmock_main.so 
#9 0x00007ffff794e17f in testing::UnitTest::Run()() from /usr/lib64/libgmock_main.so 
#10 0x00007ffff798702e in RUN_ALL_TESTS()() from /usr/lib64/libgmock_main.so 
#11 0x00007ffff7986fbd in main() from /usr/lib64/libgmock_main.so 
#12 0x00007ffff6daad1d in __libc_start_main() from /lib64/libc.so.6 
#13 0x0000000000406cc9 in _start() 

Je suis conscient que je peux contourner le problème en ajoutant tous mes EXPECT_CALLs avant Je commence le fil, mais quelqu'un d'autre l'a-t-il rencontré? Est-ce un vrai bug, et y a-t-il une solution?

Answer 1

Google Mock docs interdire explicitement entrelacer cadre de l'attente et l'appel se moque:

Note importante: Google Mock exige des attentes à être réglés avant les fonctions simulacres sont appelés, sinon le comportement est indéfini. Dans en particulier, vous ne devez pas entrelacer EXPECT_CALL() et les appels aux fonctions de simulation .