Add death tests and build in debug mode

[nahueespinosa]

Proposed changes

This makes it so we can test our assertions on CI and not run into surprises when trying to create a build with debugging information.

Type of change

• 🐛 Bugfix (change which fixes an issue)
• 🚀 Feature (change which adds functionality)
• 📚 Documentation (change which fixes or extends documentation)

Checklist

• Lint and unit tests (if any) pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)
• All commits have been signed for DCO

[nahueespinosa]

beluga_amcl tests in Noetic have a strange error 🤔.
https://github.com/Ekumen-OS/beluga/actions/runs/8010185309/job/21880630571?pr=323#step:8:9192

@hidmic Have you seen this before?

[nahueespinosa]

@hidmic I got some logs, there are "connection refused" errors preventing the test from completing: rostest-d47fb478aa75-29009.log

IIUC, ROS master is trying to communicate with the node but the connection is refused (possibly because the node is too slow?).

[hidmic]

Sorry for the delay. I had at least two false starts with this. test_amcl_nodelet is SEGFAULT'ing. Running on gdb I get:

0x000055a52592b606 in std::vector<Sophus::SE2<double, 0>, std::allocator<Sophus::SE2<double, 0> > >::size (this=0x18)
    at /usr/include/c++/9/bits/stl_vector.h:916             
916           { return size_type(this->_M_impl._M_finish - this->_M_impl._M_start); }                                     
(gdb) bt                                                                                                                  
#0  0x000055a52592b606 in std::vector<Sophus::SE2<double, 0>, std::allocator<Sophus::SE2<double, 0> > >::size (this=0x18) 
    at /usr/include/c++/9/bits/stl_vector.h:916
#1  0x000055a52591f6a8 in beluga::TupleContainer<beluga::Vector, std::tuple<Sophus::SE2<double, 0>, beluga::Numeric<double
, beluga::WeightTag, void> > >::size (this=0x0)
    at /ws/install/beluga/include/beluga/beluga/containers/tuple_vector.hpp:94
#2  0x00007f964c52d6cd in beluga_amcl::AmclNodelet::initialize_from_map (this=0x55a525b2ed20)
    at /ws/src/beluga/beluga_amcl/src/amcl_nodelet.cpp:581
#3  0x00007f964c526805 in beluga_amcl::AmclNodelet::handle_map_with_default_initial_pose (this=0x55a525b2ed20, map=...)
    at /ws/src/beluga/beluga_amcl/src/amcl_nodelet.cpp:363
#4  0x00007f964c525cfe in beluga_amcl::AmclNodelet::map_callback (this=0x55a525b2ed20, message=...)
    at /ws/src/beluga/beluga_amcl/src/amcl_nodelet.cpp:326
...

The weirdest thing is that I see:

(gdb) frame 2
#2  0x00007f964c52d6cd in beluga_amcl::AmclNodelet::initialize_from_map (this=0x55a525b2ed20)
    at /ws/src/beluga/beluga_amcl/src/amcl_nodelet.cpp:581
581       NODELET_INFO(
(gdb) list
576       }
577
578       particle_filter_->initialize_from_map();
579       enable_tf_broadcast_ = true;
580
581       NODELET_INFO(
582           "Particle filter initialized with %ld particles distributed across the map",
583           particle_filter_->particles().size());
584
585       return true;
(gdb) p particle_filter_
$12 = std::unique_ptr<beluga_ros::Amcl> = {get() = 0x0}

which makes no sense, the code could have never reached that point if particle_filter_ was nullptr.

Could it be a concurrency issue?

[nahueespinosa]

👀

ThreadSanitizer: reported 277 warnings

There are data races and lock-order-inversion warnings. I'm packed these days, but will try to look into this at some point during the week.

[nahueespinosa]

@hidmic Data races are fixed now. PTAL

[hidmic]

LGTM though codecov isn't happy (and a 5% deviation is substantial).

[nahueespinosa]

The coverage report looks weird:

https://app.codecov.io/gh/Ekumen-OS/beluga/pull/323/blob/beluga_ros/include/beluga_ros/tf2_sophus.hpp#L189

@hidmic should we keep calculating coverage from the release build?

[hidmic]

Hmm, it does look weird. I can buy it is an issue with release optimization. Let's skip coverage computations for release builds to see what happens.

[nahueespinosa]

Assuming the weirdness in coverage reports is because codecov is trying to compare a report from a release build in BASE and a debug build in HEAD, I will merge this PR and monitor the reports in the main branch.