Errors when trying to use libcxx/libcxxabi with memory sanitizer

Hi folks,

I’m trying to set up our cluster tool chain to support clang’s memory sanitizer for our multiphysics simulation program, but I can’t get it to work :-/

I started with a regularly compiled clang installation (with libcxx, libcxxabi, and libomp built in-tree). With this, I compiled all necessary third-party libraries with “-O1 -fsanitize=memory” (OpenMPI, FFTW, Parallel netCDF). Then, I compiled the libcxx/libcxxabi libraries with msan-support by checking out the llvm source and the libcxx/libcxxabi repos into the llvm/projects/ directory. I configured them with LLVM_USE_SANITIZER=Memory and put the msan-instrumented libraries in the LD_LIBRARY_PATH.

Finally, I tried to compile our tool, ZFS, with the memory sanitizer enabled and linked against the msan-compiled third-party libraries as well as the msan-instrumented libcxx/libcxxabi libraries (by putting them in the LD_LIBRARY_PATH). However, here I failed: either at configure time or at compile time (after doing some LD_LIBRARY_PATH trickery), clang exits with the following error:

/pds/opt/llvm-20151121-r253770/bin/clang++: symbol lookup error: /pds/opt/libcxx-msan-20151121-r253770/lib/libc++abi.so.1: undefined symbol: __msan_va_arg_overflow_size_tls

Any suggestions as to what I am doing wrong? Should I put the msan-instrumented libcxx in the LD_LIBRARY_PATH after compilation only?

Thanks a lot in advance

Michael

Hi folks,

I'm trying to set up our cluster tool chain to support clang’s memory
sanitizer for our multiphysics simulation program, but I can’t get it to
work :-/

I started with a regularly compiled clang installation (with libcxx,
libcxxabi, and libomp built in-tree). With this, I compiled all necessary
third-party libraries with “-O1 -fsanitize=memory” (OpenMPI, FFTW, Parallel
netCDF). Then, I compiled the libcxx/libcxxabi libraries with msan-support
by checking out the llvm source and the libcxx/libcxxabi repos into the
llvm/projects/ directory. I configured them with LLVM_USE_SANITIZER=Memory
and put the msan-instrumented libraries in the LD_LIBRARY_PATH.

Finally, I tried to compile our tool, ZFS, with the memory sanitizer enabled
and linked against the msan-compiled third-party libraries as well as the
msan-instrumented libcxx/libcxxabi libraries (by putting them in the
LD_LIBRARY_PATH). However, here I failed: either at configure time or at
compile time (after doing some LD_LIBRARY_PATH trickery), clang exits with
the following error:

/pds/opt/llvm-20151121-r253770/bin/clang++: symbol lookup error:
/pds/opt/libcxx-msan-20151121-r253770/lib/libc++abi.so.1: undefined symbol:
__msan_va_arg_overflow_size_tls

Any suggestions as to what I am doing wrong? Should I put the
msan-instrumented libcxx in the LD_LIBRARY_PATH after compilation only?

Yes, probably. In this case your compiler, which is not built with
MSan, picked up an instrumented libc++abi.
Sometimes it is convenient to set RPATH on all msan
libraries/executables and avoid LD_LIBRARY_PATH.

Thanks for your answer. Unfortunately, I cannot avoid LD_LIBRARY_PATH as it includes our cluster-wide LLVM lib dir by default on all our hosts. Thus setting RPATH at compile/link time will have no effect as there is no way to make it overrule LD_LIBRARY_PATH afaik. Instrumenting all of Clang with MSan seems a bit overkill to me (and does not solve the RPATH/LD_LIBRARY_PATH issue at runtime anyways). I guess I’ll just have to live with manually changing the LD_LIBRARY_PATH after compilation then.

Michael

Yes. Effectively you need two environments - one with
msan-instrumented libraries, and one without. Compilation should
happen in the latter (unless you want to instrument the compiler which
is not very productive), and resulting binaries should be run in the
former.

Yes. Effectively you need two environments - one with
msan-instrumented libraries, and one without. Compilation should
happen in the latter (unless you want to instrument the compiler which
is not very productive), and resulting binaries should be run in the
former.

Ah, thanks a lot. Just to be sure: is it generally OK to compile & link in an environment where ld would e.g. pick up an uninstrumented version of the OpenMPI libraries as long as the correct, instrumented OpenMPI library is in LD_LIBRARY_PATH at runtime?

Sorry for having to ask again

Michael

unsubscribe

It works in general.