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

[Kostya Serebryany via cfe-dev]

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:
https://github.com/google/sanitizers/wiki/MemorySanitizerLibcxxHowTo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160211/c6313506/attachment.html>