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

[Dan Liew via cfe-dev]

On 11 February 2016 at 17:08, 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.

Yeah I tried building Z3 with Clang without ASan and running Valgrind.
It didn't report any problems.

I don't think this is a GCC vs Clang problem. When I build Z3 with GCC
or Clang with ASan enabled both of them report
the same heap-use-after-free issue.

The original problem I reported (the divergent behaviour when building
with and without ASan, i.e. the assert being hit/not hit respectively)
should be disregarded.
I was struggling to reproduce the issue just now and I gave up and
then I accidently hit it again. Then when I tried to run valgrind on a
binary (that wasn't supposed to be built
with ASan) built by Z3's build system it complained about ASan. I
think there's something with wrong with Z3's build system and reusing
the same binary directory for non-asan / asan
build is broken in some way. Lesson learnt, always use a fresh binary
build directory!

The heap-use-after-free issue is reproducible though. I'll report out
what I found to the Z3 devs and leave it for now.

>>
>> > 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.

Thanks for pointing out. Out of interest how is MSan able to work with
a non MSan-ified glibc?

Thanks,
Dan.