Build-wrapper interferes with operation of address santiser

SonarCloud
, ,
1

Some of our projects use gcc’s address sanitiser option.
When run using the build wrapper our integration tests fail due to the emission of spurious output:

==2982443==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.

I can see that this is caused by the build wrapper injecting libinterceptor before asan so that it is no longer the first library loaded.
I’m not sure how to deal with this.

>../../../../target/sonar/build-wrapper-linux-x86/build-wrapper-linux-x86-64 --out-dir foo ldd ../../../../target/debug/test-install/opt/refcollect/bin/dateexpr --BAD
../../../../target/debug/test-install/opt/refcollect/bin/dateexpr:
	linux-vdso.so.1 (0x00007ffc8a437000)
	/home/brucea/work/git/refcollect/target/sonar/build-wrapper-linux-x86/libinterceptor-${PLATFORM}.so => /home/brucea/work/git/refcollect/target/sonar/build-wrapper-linux-x86/libinterceptor-haswell.so (0x00007fa089ab6000)
	libasan.so.5 => /usr/lib64/libasan.so.5 (0x00007fa0888c4000)

>gcc --version
gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-10)
Copyright (C) 2018 Free Software Foundation, Inc.
>lsb_release -a
LSB Version:	:core-4.1-amd64:core-4.1-noarch
Distributor ID:	RedHatEnterprise
Description:	Red Hat Enterprise Linux release 8.6 (Ootpa)
Release:	8.6
Codename:	Ootpa

build-wrapper, version 6.37 (linux-x86)
Copyright (C) 2014-2022 SonarSource SA, info@sonarsource.com

The sanitiser is easily enabled if using cmake via:

    add_compile_options("-fsanitize=null,return,leak,address,undefined")
    link_libraries("-fsanitize=null,return,leak,address,undefined")

There are two possible workarounds:

  1. disable these options when building for sonar but ideally I would like to have a single build capable of using both analyses.

  2. export ASAN_OPTIONS=verify_asan_link_order=0

“but you have to be sure that libraries from /etc/ld.so.preload do not intercept symbols important for Asan e.g. malloc, free, etc., otherwise things will start breaking” - (ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. · Issue #796 · google/sanitizers · GitHub)

Could you ask your engineering team to confirm the best approach and maybe add an entry to FAQ for the build wrapper.

I am going with option 2 for now.

4

I’m not sure option 2 is safe. In our azure build pipeline I am getting:

Indirect leak of 51 byte(s) in 1 object(s) allocated from:
#0 0x7f9b53cf1ba8 in __interceptor_malloc (/lib64/libasan.so.5+0xefba8)
#1 0x7f9b54df594a in newEnv (/__w/1/s/dependent-env/build-wrapper-linux-x86/libinterceptor-haswell.so+0x194a)
#2 0x7f9b54df5e0e in execve (/__w/1/s/dependent-env/build-wrapper-linux-x86/libinterceptor-haswell.so+0x1e0e)

Though I don’t get this on my local machine.
I need to check the surrounding code with valgrind to be sure its not the cause.

5

Hi @KantarBruceAdams ,

option 2 should be safe, it shouldn’t affect address sanitizer.

However, if that bothers you you could have a look at using CMake JSON compilation database to configure the analyzer instead of using the build-wrapper. Did you consider this option?

6

I didn’t know that was an option. Where can I find more information from the sonar angle?

I have found:

But this is broken link - https://sonarcloud.io/documentation/analysis/languages/cfamily/#analysis-steps-using-compilation-database

7

Hi @KantarBruceAdams,

you can have a look at C/C++/Objective-C | SonarCloud Docs, Analysis Steps Using Compilation Database section.

8

I’ve tried this out and its painfully easy. One line is in the CMakeLists.txt is enough:

 set(CMAKE_EXPORT_COMPILE_COMMANDS 1)

and change:

sonar.cfamily.build-wrapper-output=path/to/bw-output

to:

sonar.cfamily.compile-commands=path/to/compile_commands.json

It seems to be a much better solution.
Is there anything the build wrapper will catch that cmake will miss (or visa versa)?

I can see the recommendation is to use the build-wrapper if possible but I cannot now see a compelling reason.

9

Hi @KantarBruceAdams,

You can read more about it here: Compilation database: An alternative way to configure your C or C++ analysis

In general, CMake-generated compilation databases are accurate. As mentioned in the blog post, you need to be careful that your project compiles and that all your build-generated files (if you have any) are available during the analysis.

Thanks,