DataFlowSanitizer is a generalised dynamic data flow analysis.
Unlike other Sanitizer tools, this tool is not designed to detect a
specific class of bugs on its own. Instead, it provides a generic
dynamic data flow analysis framework to be used by clients to help
detect application-specific issues within their own code.
Differential Revision: http://llvm-reviews.chandlerc.com/D967
llvm-svn: 187924
If there's a race between a memory access and a free() call in the client program,
it can be reported as a use-after-free (if the access occurs after the free()) or an ordinary race
(if free() occurs after the access).
We've decided to use a single "race:" prefix for both cases instead of introducing a "use-after-free:" one,
because in many cases this allows us to keep a single suppression for both the use-after-free and free-after-use.
This may be misleading if the use-after-free occurs in a non-racy way (e.g. in a single-threaded program).
But normally such bugs shall not be suppressed.
llvm-svn: 187885
This reverts commit r187788.
The test case is unreliable (as the test may be run in a situation in
which it has no affinity with cpu0). This can be recommitted with a more
reliable test - possibly using CPU_COUNT != 0 instead (I wasn't entirely
sure that a process was guaranteed to have at least one affinity, though
it seems reasonable, or I'd have made the change myself).
llvm-svn: 187841
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
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
full proper list of dynamic symbols crashes old gold (see bug 16468).
the culprit is 'memcpy' function, if it's added to syms file, gold crashes
llvm-svn: 185078
restriction from the GCDAProfile.c"
Bill added a much more effective way of coping with the use of errno and
other system interactions for Darwin for now by disabling it on that
platform. Building against the SDK stuff is more fundamental to the
darwin build process.
llvm-svn: 184929
(thanks!) by deferring the free of the filename until we finish writing
the coverage data to that file.
Bill, let me know if you'd prefer a different approach!
llvm-svn: 184895
darwin.
After talking with Jim Grosbach pretty extensively, he was OK with me
punting on this to the Apple folks.
We agreed that the correct fix is either to extend the fake SDK headers
in compiler-rt to support the rest of libc needed by GCDAProfiling.c or
to teach the make build to test for the existence of a suitable SDK on
the system prior to building it. Both of these require someone with
access to the SDK which I don't have, and the latter (my preferred
solution) requires understanding the strange compiler-rt make build
system. Punting to Dan Dunbar or one of the others who support this
stuff on ios to write the appropriate fix, and we can let the build bots
proceed in the mean time.
llvm-svn: 184816
runtime in the Makefile build system as well. Sorry for the temporary
fallout, it took me a while to find these bits.
Bill, I'm not at all confident of the change for Darwin and iOS, but as
discussed we're completely blocked on fixing this. Anyways, please
review and let me know if this will work for you guys. If necessary,
I can work with you to rig up an errno.h stub for Darwin, but I expect
that to be... moderately challenging.
llvm-svn: 184805
through Bill's patch:
1) Correctly test the file descriptor after the sceond attempt at
creating the file.
2) Make the filename a global so that we can issue error messages from
other routines.
3) Check errno in several places and print it out so that errors are
easier to track down.
I don't really expect any of these to fix the current failures I'm
seeing, but I'm hopeful they'll at least let me debug them.
llvm-svn: 184799
We really need the C standard library to be available to implement the
profiling runtime library reasonably, and replicating everything in the
SDKs tree really isn't addressing any problems we have. Notably, all of
the sanitizer runtimes take the same approach, and this isn't a library
which could end up in a bootstrapping problem where the system headers
aren't even available.
This will hopefully prevent subsequent changes which start using various
other bits of C standard library to make things more debuggable.
llvm-svn: 184798
Dmitry Vyukov