[llvm-dev] [cfe-dev] Buildling with/without AddressSanitizer causes divergent execution behaviour

Kostya Serebryany via llvm-dev llvm-dev at lists.llvm.org
Thu Feb 11 10:41:42 PST 2016

On Thu, Feb 11, 2016 at 9:08 AM, Reid Kleckner <rnk at google.com> wrote:

> On Thu, Feb 11, 2016 at 5:53 AM, Dan Liew via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>> > Can you somehow verify that this heap-use-after-free is happening?
>> > E.g. print all the pointer values coming from memory::allocate, coming
>> into
>> > memory::deallocate, and coming into sat::clause::operator[]
>> >
>> > If curious, check what size of quarantine is required to catch this bug
>> > (ASAN_OPTIONS=quarantine_size_mb=N, default=256)
>> > Valgrind may have smaller default quarantine and thus misses this bug.
>> I was lazy and just told valgrind to execute the program (built by gcc
>> without ASan) with the largest quarantine it supported.
> There are some differences between Clang and GCC, such as left-to-right vs
> right-to-left argument evaluation. This usually bites people who are moving
> unique_ptr or vector and accessing it in the same expression. Given the
> stack traces, I suspect that different orderings of refcount operations is
> what's happening here. I would suggest building Z3 with Clang without ASan
> and running valgrind on that.
>> > Did you try msan?
>> I just have and it immediately reported a problem. I took a closer
>> look and it looks like a false positive to me.
> ...
> This is because your STL was not compiled with MSan. The std::ofstream
> constructor is provided by libstdc++, the writes are not instrumented, and
> MSan never sees the initialization. Unfortunately, MSan is not very useful
> unless you recompile your *entire* application minus glibc with msan. =/
> It is possible to build an MSan-ified libc++ and use it if you want to
> keep trying, but it's involved.
Exact steps:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160211/c6313506/attachment.html>

More information about the llvm-dev mailing list