pilz_robots
pilz_robots copied to clipboard
PilzDE
Add sanitizing build job
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.
For information on how-to execute a sanitizer locally see PR pilzde/.github#7.
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).
+1 for adding sanitizing
Why not use cmake arguments instead of environment variables for ENABLE_ADDRESS_SANITIZING, etc.?
Good question :smile: I will give it a try.
+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.
+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 :see_no_evil: ARRRRRRRGH... I want to merge.
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).
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.
