googletestros2colcon

GTest launched through colcon gets SEGFAULT

I'm using colcon to run tests for my ROS2 application. Up until now I haven't had any problems, but now after adding a simple fixture

class ElectionTest : public ::testing::Test {
    protected:
        ElectionModule core_;
};

and relative tests it seems like the underlying GTest is crashing: in the test summary I see

[ RUN      ] ElectionTest.CantPrepareTopics
-- run_test.py: return code -11
-- run_test.py: generate result file '/home/slim71/Documents/git/SpartanLIFT/build/pelican/test_results/pelican/pelican_test.gtest.xml' with failed test
-- run_test.py: verify result file '/home/slim71/Documents/git/SpartanLIFT/build/pelican/test_results/pelican/pelican_test.gtest.xml'

and everything stops of course. Code -11 should be SEGFAULT, which I don't know where is coming from.

Introducing some cout here and there I can see that the crash happens after calling the object destructor, but then I don't know what the problem can be. If the ElectionModule destructor is being called before the test ends, my guess is that there's no problem with my class...

Is there any way to debug or find out more?

Solution

  • In the end, my "guess" was wrong! It was indeed due to my code (which to be honest is always the most probable explanation): there was indeed some problem in the use of pointers, so it would have been better if I shared at least parts of it..

    To be precise, in case anybody else stumbles in this: it seemed like something out of my code because it was the invoked at the very end of the destructor. I was using RCLCPP_DEBUG_STREAM with an empty pointer to rclcpp::Logger. I had added a boolean check, aka if(logger_), but since logger_ wasn't initialized to a nullptr I guess here and there the boolean conversion passed and the code tried to access some protected memory. Definitely my bad!

    The most useful thing I got from this, which I'll share just in case, is how to correctly debug the ROS2 executable used by colcon test:

    1. Be sure to compile the executable with debug info, i.e. by adding set(CMAKE_BUILD_TYPE Debug) in the CMakeLists.txt.
    2. Get the path to the compiled executable (for example, you can manually launch colcon testand inspect the summary, like I did)
    3. Just launch that executable in the debugger with the appropriate command! I've used gdbtui /path/to/test_exe



    Well, I guess the loss in reputation is what I get from this! ¯_(ツ)_/¯