shameless self-promoting website
»Rejourn root
»LibreOffice Community Blogs

sanitizers (ASAN, UBSAN, etc.) is a collection of tools to detect memory corruption bugs, undefined behavior and more by instrumenting the code generated by the compiler. (That’s the main difference from valgrind.) From LibreOffice’s perspective one more important difference is that there is a Jenkins_Linux_Ubsan tinderbox that makes sure that the master branch is kept clean from errors detected by a given configuration.

So when the tinderbox failed after a commit of mine, I wanted to set up a similar environment locally, reproduce and fix the bug, and push the fix once I saw that the fix indeed solves the problem. You can set many options both at build and runtime, so while we have some documentation on the TDF wiki (and also Stephan was kind enough to share his config) on how to use these sanitizers, it wasn’t clear to me what to do step by step. So here is one possible setup that worked for me — in my case I wanted to reproduce a stack-use-after-return problem. If you haven’t ever built LibreOffice before, then go to the Development wiki page, first do a normal build, and if everything went fine, came back here.

Build options

My autogen.input looks like this:

CC=clang -fsanitize=address
CXX=clang++ -fsanitize=address

Which is a normal clang debug build, except:

  • you need to add -fsanitize=... to CXX (not to CXXFLAGS), as explained on the wiki

  • you need to explicitly disable Firebird integration for now


My first attempt failed at build time, as even the tools used only during the build are instrumented, and some memory leak was detected there, which means the build aborted before reaching the problem I was interested in. To disable leak detection during build, and disable parallelism (I needed this, as I did the build in the background while using the machine for something else):

make build-nocheck ASAN_OPTIONS=detect_leaks=0 PARALLELISM=1

This also means that I explicitly disabled running any tests, as I knew which is the single unit test I want to run for the purposes of reproducing and fixing the problem.


Once the build completed, it turns out that the stack-use-after-return detection is disabled at runtime by default, which means I could not see any problem locally. Here is the commandline to run one specific CppunitTest with this detection on:

cd sw; make -sr CppunitTest_sw_tiledrendering ASAN_OPTIONS=detect_leaks=0:detect_stack_use_after_return=1

Again, this is just one possible setup, you can use other -fsanitize=... options, other environment variables during build and during testing — but hopefully it helps in the future to avoid pushing fixes for such problems detected by sanitizers just blindly.