Add sanitizing build job

[HiddenBug]

This PR adds sanitizing as CI jobs to the pilz_robots repository.

[agutenkunst]

Really like having these checks included in the CI. Maybe even interesting for a upstream PR on industrial_ci. Just some minor remarks.

Just as an idea. This would be nice to have as a dedicated package just like https://github.com/mikeferguson/code_coverage for providing a simple macro to enable the sanitizing. However this is far beyond the scope of this PR. Maybe https://github.com/agutenkunst/cmake_extras_demo_pkg could be a starting point.

[HiddenBug]

We could split the commits which are only needed to satisfy the clang compiler into a separate PR. @agutenkunst What do you think? See PR #283.

[HiddenBug]

For information on how-to execute a sanitizer locally see PR PilzDE/.github#7.

[HiddenBug]

As it turns out gcc already supports address and undefined behavior sanitizing (see gcc online documentation).
Furthermore, using clang introduces false-positive error detection's. This seems to happen when a library is not build with clang or something.
There also exists a thread sanitizer but I got a lot of errors using this sanitizer. So I decided to introduce the thread sanitizer later on and just introduce the address and undefined behavior sanitizer in this PR.

Memory sanitizing is only available with clang. However, every dependency needs to be build with the memory sanitizing flags (described for example in the rosproject-scripts repo on GitHub). Therefore, I decided to skip this sanitizer completely (at least for the moment).

[leunMar]

👍 for adding sanitizing

Why not use cmake arguments instead of environment variables for ENABLE_ADDRESS_SANITIZING, etc.?

[HiddenBug]

+1 for adding sanitizing

Why not use cmake arguments instead of environment variables for ENABLE_ADDRESS_SANITIZING, etc.?

Good question 😄 I will give it a try.

[HiddenBug]

+1 for adding sanitizing

Why not use cmake arguments instead of environment variables for ENABLE_ADDRESS_SANITIZING, etc.?

OK. I only use the travis config file now. This should satisfy you.

[HiddenBug]

+1 for adding sanitizing
Why not use cmake arguments instead of environment variables for ENABLE_ADDRESS_SANITIZING, etc.?

OK. I only use the travis config file now. This should satisfy you.

But now I get sanitizing errors in the repositories previously not included 🙈 ARRRRRRRGH... I want to merge.

[HiddenBug]

Interesting fact:
The address sanitizer detects a memory leak in libclass_loader, more precisely in /opt/ros/melodic/include/class_loader/class_loader_core.hpp:205 (see Travis log). However, for some reason, maybe because the memory leak detection happens in another process as the test is running in, it does not lead to a test failure. I only see the error output message from the address sanitizer (or more precisely from the LeakSaniatizer).

[martiniil]

Only guessing: from class_loader_core.cpp:

       // Insert into graveyard
        // We remove the metaobject from its factory map, but we don't destroy it...instead it
        // saved to a "graveyard" to the side.
        // This is due to our static global variable initialization problem that causes factories
        // to not be registered when a library is closed and then reopened.
        // This is because it's truly not closed due to the use of global symbol binding i.e.
        // calling dlopen with RTLD_GLOBAL instead of RTLD_LOCAL.
        // We require using the former as the which is required to support RTTI

This "graveyard" is a std::vector holding raw pointers. So maybe that is why these metaobjects are not destroyed.

[martiniil]

I opened an issue: ros/class_loader#131