Regarding the issue of not being able to start Sanitizers when using Gazebo

Help
, , ,
1

I hope to detect memory issues in Gazebo, but I have encountered trouble.

Firstly, the official manual` Contributing to Gazebo — Gazebo jetty documentation -It is recommended to use Sanitizers in tests, so I tried to compile and run according to the process in the manual. My environment is Ubuntu 24.04, and I use source code compilation and installation. The compilation command is

colcon build --build-base=build-asan --install-base=install-asan \
--cmake-args -DCMAKE_BUILD_TYPE=Debug \
--mixin asan-gcc

as well as

colcon build --executor parallel --parallel-workers 15 --cmake-args \
-DCMAKE_BUILD_TYPE=Debug \
-DCMAKE_C_COMPILER=$CC \
-DCMAKE_CXX_COMPILER=$CXX \
-DCMAKE_C_FLAGS="-fprofile-arcs -ftest-coverage -fsanitize=address" \
-DCMAKE_CXX_FLAGS="-fprofile-arcs -ftest-coverage -fsanitize=address" \
-DCMAKE_EXE_LINKER_FLAGS="-fsanitize=address -fprofile-arcs" \
-DCMAKE_SHARED_LINKER_FLAGS="-fsanitize=address -fprofile-arcs" \
--merge-install

However, regardless of which compilation command is used, when starting ‘gz sim shapes. sdf’ after successful compilation, a massive number of errors are reported in the terminal, and the gz sim process is shut down. If Asan is not added, I can start ‘gz sim shapes. sdf’ normally.

The errors in the terminal are shown in the following figure

D10372F16928B862B77A891D3AB1DB23
D10372F16928B862B77A891D3AB1DB231920×1080 392 KB

I also tried using asan on Ubuntu 22.04, gz sim 8 version, but it couldn’t compile successfully. I kept getting stuck compiling the gz msgs module, and the memory usage exceeded my computer’s limit of 128GB and froze. Adding the ‘-- parallel workers 15’ option will not freeze the process, but the compilation progress will not increase, only until the gz msgs module is compiled.

I would like to know why and how to solve the above two questions

2

Building with sanitizers works to some degree for unit/integration tests. When you run Gazebo with the gz sim command, it actually invokes a ruby script that loads a shared library of the desired Gazebo version. This added complexity makes it difficult for sanitizers to work since the Ruby executable itself is not compiled with sanitizer support. It might also have its own memory issues, so it’ll spew out a lot of errors that are not related to Gazebo. If you’re debugging a memory problem, my suggestion is to create your own integration test (examples). These create an instance of Gazebo without going through Ruby, so the sanitizers are likely to work. BTW, you can just pass -DGZ_SANITIZER=Address as a cmake argument to enable the address sanitizer (see tutorial).

128GB should be plenty to compile Gazebo, so I’m not sure why you’re having memory issues. You can try --executor sequential so colcon doesn’t parallelize packages. You can also try setting an environment variable MAKEFLAGS="-j 1" so make itself only uses a single job per build.