On Tue, Nov 24, 2015 at 9:12 AM, Schlottke-Lakemper, Michael via cfe-users <
cfe-users@lists.llvm.org> wrote:
> 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
Try to add ASAN_OPTIONS=fast_unwind_on_malloc=0. It's possible that stack
traces go through smth. like libstdc++ which is built without frame
pointers.
On Tue, Nov 24, 2015 at 12:49 AM, Rainer Gerhards via cfe-users <
cfe-users@lists.llvm.org> wrote:
> Hi all,
>
> first, thanks for the great tool
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, libcxxa
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
Hi Evgenii,
I can confirm that adding
LIBS=“-lutil”
to the configure command for OpenMPI resolved the reported issue. Thanks again
for your help!
Michael
> On 23 Nov 2015, at 20:05 , Evgenii Stepanov wrote:
>
> I think so. What probably happens here is MSan confuses the configure
> script
Hi all,
first, thanks for the great tool, especially the address sanitizer. I
have a multi-threaded program, where I get a segfault due to access to
free'd memory in one thread. In the report, I see references to where
this memory block was malloc'ed and free'ed. Unfortunately, these
later two sta
