Why is Google Test segfaulting? - c++

Question

I'm new to Google Test and I'm playing around with the provided examples. My issue is, when I introduce a failure and set GTEST_BREAK_ON_FAILURE=1 (or use the command line option), GTest will segfault.
I am considering this example. If I insert something like this into any of the tests, I will start to get the segfault:
EXPECT_EQ(8, 2*3);
Just to reiterate, that is only when I have also set GTEST_BREAK_ON_FAILURE=1. I have run from the command line and also with gdb. If that environment variable is not set, it reports the error but does not segfault.
Any clue to what could be causing this/what I am doing wrong? I've been looking for a similar issue, but I haven't run into anything yet.
FYI I am using Google Test version 1.7.0 running on 64 bit CrunchBang Linux 11 "Waldorf".
edit code sample:
// Tests factorial of positive numbers.
TEST(FactorialTest, Positive) {
EXPECT_EQ(1, Factorial(1));
EXPECT_EQ(2, Factorial(2));
EXPECT_EQ(6, Factorial(3));
EXPECT_EQ(40320, Factorial(8));
}
Debugger output:
(gdb) run
Starting program: /home/yourfavoriteprotein/bin/cpp_unit_test_frameworks/gtest-1.7.0/samples/mytest
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Running main() from test_main.cc
[==========] Running 6 tests from 2 test cases.
[----------] Global test environment set-up.
[----------] 3 tests from FactorialTest
[ RUN ] FactorialTest.Negative
[ OK ] FactorialTest.Negative (0 ms)
[ RUN ] FactorialTest.Zero
[ OK ] FactorialTest.Zero (0 ms)
[ RUN ] FactorialTest.Positive
sample1_unittest.cc:112: Failure
Value of: 2*3
Actual: 6
Expected: 8
Program received signal SIGSEGV, Segmentation fault.
0x0000000000413427 in testing::UnitTest::AddTestPartResult(testing::TestPartResult::Type, char const*, int, std::string const&, std::string const&) ()
(gdb) quit

Answer 1

GTEST_BREAK_ON_FAILURE=1 means that Google Test drops you into the debugger if a test fails.
It so happens that an easy, portable way to drop you into the debugger is to trigger a segfault.
In other words, this behavior is by design; Google Test deliberately triggers a segfault to make the debugger run. (See here in the Google Test code.)