Previously (in tools other than TSan) the entire prefix of the path had to mach
the argument. With this change, only some suffix of the prefix has to match.
This is the same way this flag works in TSan.
llvm-svn: 186837
It is required for chromium sandboxing code.
From the description it seems to be indeed synchronous -- called back on syscall with incorrect arguments,
but seems to be unused in practice. So this should be fine.
llvm-svn: 186579
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
Sergey Matveev