Hi folks,
When running our msan-instrumented simulation program, instead of a proper output I get the following error:
==12089==WARNING: MemorySanitizer: use-of-uninitialized-value
==12089==WARNING: Can’t read from symbolizer at fd 14
/pds/opt/llvm/bin/llvm-symbolizer: symbol lookup error: /pds/opt/libcxx-20151121-r253770-clang-msan/lib/libc++abi.so.1: undefined symbol: __msan_origin_tls
==12089==WARNING: external symbolizer didn’t start up correctly!
My setup for using the memory sanitizer is as follows:
- compile libc++/libc++abi with -fsanitize=memory
- compile test program with normal (=uninstrumented) LLVM/Clang installation using -fsanitize=memory
- put instrumented libcxx/libcxxabi library dirs into LD_LIBRARY_PATH
- run program
Any idea what I am doing wrong? Thanks a lot in advance!
Michael
Short update: I thought the behavior reported below it might be related to the fact that llvm-symbolizer picks up the “wrong” (i.e. the msan-implemented) version of libc++ once I put it in the LD_LIBRARY_PATH. Thus I tried to compile a complete LLVM/Clang stack (with compiler-rt, libcxx, libcxxabi, libomp) using -DLLVM_USE_SANITIZER=MemoryWithOrigins. However, this did not work either, as apparently during the compilation process the memory sanitizer already comes to life and complains about use-of-unitialized values… Thus this approach seems to be a dead end.
Michael
Short update: I thought the behavior reported below it might be related to
the fact that llvm-symbolizer picks up the “wrong” (i.e. the
msan-implemented) version of libc++ once I put it in the LD_LIBRARY_PATH.
Yes, I think that's what happening.
Thus I tried to compile a complete LLVM/Clang stack (with compiler-rt,
libcxx, libcxxabi, libomp) using -DLLVM_USE_SANITIZER=MemoryWithOrigins.
However, this did not work either, as apparently during the compilation
process the memory sanitizer already comes to life and complains about
use-of-unitialized values… Thus this approach seems to be a dead end.
Michael
Hi folks,
When running our msan-instrumented simulation program, instead of a proper
output I get the following error:
==12089==WARNING: MemorySanitizer: use-of-uninitialized-value
==12089==WARNING: Can't read from symbolizer at fd 14
/pds/opt/llvm/bin/llvm-symbolizer: symbol lookup error:
/pds/opt/libcxx-20151121-r253770-clang-msan/lib/libc++abi.so.1: undefined
symbol: __msan_origin_tls
==12089==WARNING: external symbolizer didn't start up correctly!
My setup for using the memory sanitizer is as follows:
- compile libc++/libc++abi with -fsanitize=memory
- compile test program with normal (=uninstrumented) LLVM/Clang
installation using -fsanitize=memory
- put instrumented libcxx/libcxxabi library dirs into LD_LIBRARY_PATH
Can you pass -Wl,-rpath when you link your executable, to specify the path
to instrumented libc++/libc++abi?
Yes, and if I do that together with setting LD_LIBRARY_PATH=“”, it works, thanks. The problem with this approach, however, is that on our cluster installation, LD_LIBRARY_PATH by default includes LLVM’s lib dir. If I want the MemorySanitizer to work for all users, I somehow need to find another way that may involve adding paths to LD_LIBRARY_PATH, but not removing them. Any idea how I could achieve this?
Thanks,
Michael
Thus I tried to compile a complete LLVM/Clang stack (with compiler-rt,
libcxx, libcxxabi, libomp) using -DLLVM_USE_SANITIZER=MemoryWithOrigins.
However, this did not work either, as apparently during the compilation
process the memory sanitizer already comes to life and complains about
use-of-unitialized values… Thus this approach seems to be a dead end.
Michael
Hi folks,
When running our msan-instrumented simulation program, instead of a
proper output I get the following error:
==12089==WARNING: MemorySanitizer: use-of-uninitialized-value
==12089==WARNING: Can't read from symbolizer at fd 14
/pds/opt/llvm/bin/llvm-symbolizer: symbol lookup error:
/pds/opt/libcxx-20151121-r253770-clang-msan/lib/libc++abi.so.1: undefined
symbol: __msan_origin_tls
==12089==WARNING: external symbolizer didn't start up correctly!
My setup for using the memory sanitizer is as follows:
- compile libc++/libc++abi with -fsanitize=memory
- compile test program with normal (=uninstrumented) LLVM/Clang
installation using -fsanitize=memory
- put instrumented libcxx/libcxxabi library dirs into LD_LIBRARY_PATH
Can you pass -Wl,-rpath when you link your executable, to specify the
path to instrumented libc++/libc++abi?
Yes, and if I do that together with setting LD_LIBRARY_PATH=“”, it works,
thanks.
Why do you need to clear LD_LIBRARY_PATH to run MSan?
What libraries from LLVM lib dir harm running the MSan-ified executalbe? I
thought that if you set rpath to correct path with instrumented libraries
it should be enough...
Right now I have the problem that by default, LD_LIBRARY_PATH includes a directory with libc++/libc++abi in it. However, when running msan-instrumented executables to test them, the executable should pick up msan-instrumented versions of libc++/libc++abi while the subsequently used llvm-symbolizer needs to pick up the uninstrumented versions (otherwise I get the above-mentioned errors). Setting rpath is not enough, since the presence of libc++/libc++abi in LD_LIBRARY_PATH will override it. Compiling llvm-symbolizer in a way that it is able to run with msan-instrumented libc++ might be an option, but I don’t know how to do that (other than compiling all of LLVM with msan, which does not work either).
One possible workaround that I have been using is to create a shell script, call it “llvm-symbolizer”, put
LD_LIBRARY_PATH=“$LLVM_DIR/lib:$LD_LIBRARY_PATH” $LLVM_DIR/bin/llvm-symbolizer $*
in it, and make sure that it is on the PATH before the actual llvm-symbolizer executable (which is located in LLVM_DIR/bin). However, this is clearly a workaround and I am looking for a more robust and more “canonical” solution.
Any suggestions?
Michael
Instead of putting the directory that contains libc++/libc++abi into LD_LIBRARY_PATH, use the system’s ‘normal’ method of locating libraries, by ensuring that directory is included in the search path built up from /etc/ld.so.conf. If you do this, then an RPATH in an executable will take precedence over the default directory, because the default directory won’t be specified in LD_LIBRARY_PATH (which has the highest precedence).
Instead of putting the directory that contains libc++/libc++abi into LD_LIBRARY_PATH, use the system’s ‘normal’ method of locating libraries, by ensuring that directory is included in the search path built up from /etc/ld.so.conf. If you do this, then an RPATH in an executable will take precedence over the default directory, because the default directory won’t be specified in LD_LIBRARY_PATH (which has the highest precedence).
This, of course, would be the preferred solution. Unfortunately, while it is possible for me to influence the values in LD_LIBRARY_PATH, I cannot easily update the ldconfig cache on all cluster nodes (if at all). I am thus still interested in (and actively searching for) an alternative approach.
Michael