Summary:
This change makes races between updates of thread-local stats and
merging all the thread-local stats together less harmful.
Reviewers: kcc
Reviewed By: kcc
CC: dvyukov, llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1572
llvm-svn: 189744
This change adds a Python script that is invoked for
the just-built sanitizer runtime to generate the list of exported symbols
passed to the linker. By default, it contains interceptors and sanitizer
interface functions, but can be extended with tool-specific lists.
llvm-svn: 189356
This sets flags and excludes things that aren't working with MSVC yet,
allowing us to build the ASan runtime as part of the cmake build.
Differential Revision: http://llvm-reviews.chandlerc.com/D1525
llvm-svn: 189304
We needed a way to tell LSan to invoke leak checking only if __do_leak_check()
is called explicitly. This can now be achieved by setting
leak_check_at_exit=false.
llvm-svn: 187578
First, the reason I came here: I forgot to look at readdir64_r which had
the exact same bug as readdir_r. However, upon applying the same
quick-fix and testing it I discovered that it still didn't work at all.
As a consequence, I spent some time studying the code and thinking about
it and fixed several other problems.
Second, the code was checking for a null entry and result pointer, but
there is no indication that null pointers are viable here. Certainly,
the spec makes it extremely clear that there is no non-error case where
the implementation of readdir_r fails to dereference the 'result'
pointer and store NULL to it. Thus, our checking for a non-null 'result'
pointer before reflecting that write in the instrumentation was
trivially dead. Remove it.
Third, the interceptor was marking the write to the actual dirent struct
by looking at the entry pointer, but nothing in the spec requires that
the dirent struct written is actually written into the entry structure
provided. A threadlocal buffer would be just as conforming, and the spec
goes out of its way to say the pointer to the *actual* result dirent
struct is stored into *result, so *that* is where the interceptor should
reflect a write occuring. This also obviates the need to even consider
whether the 'entry' parameter is null.
Fourth, I got to the bottom of why nothing at all worked in readdir64_r
-- the interceptor structure for dirent64 was completely wrong in that
it was the same as dirent. I fixed this struct to be correct (64-bit
inode and 64-bit offset! just a 64-bit offset isn't enough!) and added
several missing tests for the size and layout of this struct.
llvm-svn: 186109
directory stream, the entry is not written to, instead *result is set to
NULL and the entry is not written to at all.
I'm still somewhat suspicious of the correct instrumention here --
I feel like it should be marking the written range as the pointer in
*result and the length (*result)->d_reclen in case the implementation
decides not to use the passed-in entry (if that's even allowed).
Finally, the definition of 'struct dirent' analog used in the
interceptor is wrong in 32-bit mode with _FILE_OFFSET_BITS=64 as it hard
codes the use of a pointer-sized offset.
I've added a somewhat goofy test for the bug I fixed via ASan --
suggestions on how to better test the interceptor logic itself welcome.
llvm-svn: 185998
Update the main thread's os_id on every pthread_create, and before
initiating leak checking. This ensures that we have the correct os_id even if we
have forked after Init().
llvm-svn: 185815
Kostya Serebryany