asan: odr-violation false alarm with shared libraries

[taewookoh]

Hello,

It seems that there's a case of false odr-violation alarm with shared objects. Below is my code:

--- template.h

template<typename T>
class Base {
public:
  Base() = default;
  virtual ~Base() = default;
};

template<typename T>
class Derived : Base<T> {
public:
  Derived() = default;
  ~Derived() {};
};


--- weak.cpp

#include <iostream>
#include <typeinfo>
#include "template.h"

void weak() {
  std::cout << typeid(Derived<int>).name() << "\n";
  std::cout << typeid(Derived<char>).name() << "\n";
}

--- strong.cpp

#include <iostream>
#include <typeinfo>
#include "template.h"

template<>
class Derived<int> : Base<int> {
public:
  Derived() = default;
  ~Derived();
};

template<>
class Derived<char> : Base<char> {
public:
  Derived() = default;
  ~Derived();
};


Derived<int>::~Derived() {}
Derived<char>::~Derived() {}

void strong() {
  std::cout << typeid(Derived<int>).name() << "\n";
  std::cout << typeid(Derived<char>).name() << "\n";
}

--- main.cpp

extern void weak();
extern void strong();

int main() {
  weak();
  strong();
}

--- Makefile

CLANG=~/llvms/upstream-git/install-debug/bin/clang++

all: run

%.o: %.cpp
        $(CLANG) -fPIC -c -fsanitize=address -o $@ $^

lib%.so: %.o
        $(CLANG) -fPIC -shared -o $@ $^

main-strong: main.o libstrong.so libweak.so
        $(CLANG) -fPIC -fsanitize=address -o $@ main.o libstrong.so libweak.so -L. -lstrong -lweak

main-weak: main.o libstrong.so libweak.so
        $(CLANG) -fPIC -fsanitize=address -o $@ main.o libweak.so libstrong.so -L. -lweak -lstrong

run: main-strong main-weak
        LD_LIBRARY_PATH=. ./main-strong
        LD_LIBRARY_PATH=. ./main-weak

clean:
        rm -f *.so *.o main-strong main-weak

And below is the result from make run:

LD_LIBRARY_PATH=. ./main-strong
7DerivedIiE
7DerivedIcE
7DerivedIiE
7DerivedIcE
LD_LIBRARY_PATH=. ./main-weak
==1511755==The following global variable is not properly aligned.
==1511755==This may happen if another global with the same name
==1511755==resides in another non-instrumented module.
==1511755==Or the global comes from a C file built w/o -fno-common.
==1511755==In either case this is likely an ODR violation bug,
==1511755==but AddressSanitizer can not provide more details.
=================================================================
==1511755==ERROR: AddressSanitizer: odr-violation (0x7f91069c5249):
  [1] size=12 'typeinfo name for Derived<char>' strong.cpp
  [2] size=12 'typeinfo name for Derived<char>' strong.cpp
These globals were registered at these points:
  [1]:
    #0 0x434e17  (/data/users/twoh/tmp/weakso/main-weak+0x434e17)
    #1 0x7f91067c168b  (libstrong.so+0x168b)

  [2]:
    #0 0x434e17  (/data/users/twoh/tmp/weakso/main-weak+0x434e17)
    #1 0x7f91067c168b  (libstrong.so+0x168b)

==1511755==HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_odr_violation=0
SUMMARY: AddressSanitizer: odr-violation: global 'typeinfo name for Derived<char>' at strong.cpp
==1511755==ABORTING

If I checked the IR, _ZTS7DerivedIcE has external linkage in strong.cpp, while it has linkonce_odr linkage in weak.cpp. As ASAN doesn't instrument weak symbols, _ZTS7DerivedIcE is not aligned in libweak.so as

nm libweak.so | grep _ZTS7DerivedIcE
0000000000001249 V _ZTS7DerivedIcE

. So it seems that if dynamic linker observes weak symbol (from libweak.so) before the strong symbol (From libstrong.so) as in the case of main-weak binary, odr-violation is reported from here (https://github.com/llvm-mirror/compiler-rt/blob/master/lib/asan/asan_globals.cc#L200) when the registration is attempted from the instrumentation for the strong symbol.

I was able to repro this issue from top-of-trunk. I wonder if there's any fix or work around available. Thanks!

[taewookoh]

I'm not very familiar with ASAN implementation, but what's the reason behind not instrumenting weak symbols? I wonder if we can consider just padding weak symbols to force alignment to avoid cases like this?

[yugr]

@chefmax Perhaps will be fixed with indicators?

[chefmax]

@taewookoh can you try adding -mllvm -asan-use-private-alias=1 to your compilation flags?

[yugr]

And export ASAN_OPTIONS=use_odr_indicator=1 before running?

[taewookoh]

@yugr @chefmax Thanks for the comments! Though export ASAN_OPTIONS=use_odr_indicator=1 doesn't work, -mllvm -asan-use-private-alias=1 made the issue go away. Is there a particular reason we don't set the flag by default?

[chefmax]

@taewookoh I don't remember exact reasons, perhaps just nobody cared enough. FYI GCC uses private aliases unconditionally.
Btw, if you want more details about this issue, you can find them here: https://github.com/google/sanitizers/wiki/AddressSanitizerClangVsGCC-(6.0-vs-8.1)#feature-1

[taewookoh]

@chefmax I see. Thank you!

[yugr]

@kcc Any plans to enable indicators by default?

[kcc]

No plans -- nobody is working on that code currently, sorry.

[yugr]

I don't think any work is needed, just flipping the default value of those two switches.

[micahsnyder]

@yugr @chefmax Thanks for the comments! Though export ASAN_OPTIONS=use_odr_indicator=1 doesn't work, -mllvm -asan-use-private-alias=1 made the issue go away. Is there a particular reason we don't set the flag by default?

I gave this an initial thumbs up because -mllvm -asan-use-private-alias=1 resolved the issue for myself on a macOS 10.14 (Mojave) VM. I never had this ODR false positive on my macOS 10.14 host.

My QA engineer reported this ODR false positive issue on his macOS 10.13 host or 10.13 and 10.14 VMs. We didn't realize until just this moment that ASAN_OPTIONS is a runtime flag for our fuzz targets, not a compile time flag (https://github.com/google/sanitizers/wiki/AddressSanitizerFlags#run-time-flags). I had the QA engineer test something along the lines of ASAN_OPTIONS=use_odr_indicator=1 ./project-api-fuzzer <testcase> as well, but it didn't make any difference.

For context, we're using oss-fuzz. It's rather trivial to do validation testing with oss-fuzz's docker image and helper scripts, but the issue crops up when we build our standalone fuzz targets outside of Docker on select machines.

[MaskRay]

This can be closed now.