dvyukov (Dmitry Vyukov)
User

Projects

User does not belong to any projects.

User Details

User Since
Dec 6 2012, 2:31 AM (266 w, 5 d)

Recent Activity

Dec 13 2017

dvyukov accepted D41190: [tsan] Separate the constants in libignore and bump the maximum for instrumented libraries.

LGTM with a nit

Dec 13 2017, 11:54 PM · Restricted Project

Dec 5 2017

dvyukov accepted D40877: [TSan] Make more TSan interceptors symbolizer-aware..
Dec 5 2017, 10:42 PM

Dec 4 2017

dvyukov accepted D40726: Move __tsan::Vector to __sanitizer.
Dec 4 2017, 4:27 AM · Restricted Project

Dec 1 2017

dvyukov added inline comments to D40714: Correct atexit(3) support in MSan/NetBSD.
Dec 1 2017, 4:53 AM · Restricted Project

Nov 30 2017

dvyukov accepted D40665: [sanitizer] Implement NanoTime() on Darwin.
Nov 30 2017, 12:08 PM · Restricted Project
dvyukov accepted D40666: [sanitizer] Use MADV_FREE on Darwin/BSD to release pages to the OS.
Nov 30 2017, 12:08 PM · Restricted Project

Nov 29 2017

dvyukov added a comment to D40545: [sanitizer] add msvc atomic_compare_exchange_strong for sint32_t.

this is used in x-ray runtime , in xray_fdr_logging.cc ,such as line 56:

if (!__sanitizer::atomic_compare_exchange_strong(
         &LogFlushStatus, &Result, XRayLogFlushStatus::XRAY_LOG_FLUSHING,
         __sanitizer::memory_order_release))

currently x-ray didn't compile on windows,but this is a little step to make it build. I'm trying to build xray runtime on windows, some talks here:
http://lists.llvm.org/pipermail/llvm-dev/2017-November/119218.html

That's the one I referred to as "which should actually use atomic_uint32_t".
Please switch xray to uint32. I don't think we want to support all of 10 atomic operations X 6 memory orderings X 20 different types, that's more than 1000 combinations.
One day we should finally switch to C++ atomics, but until then it does not make sense to grow set of atomic operations infinitely.

I'm curious though, since that type is coercing an enum into an int, which is the only defined conversion as far as I can tell. While it "should" be safe to use atomic_uint32_t instead, I'm wondering whether it's actually safe to do that. If it is, then I'm happy with using atomic_uint32_t instead of an atomic_int32_t in XRay.

Nov 29 2017, 6:16 AM · Restricted Project
dvyukov added a comment to D40545: [sanitizer] add msvc atomic_compare_exchange_strong for sint32_t.

this is used in x-ray runtime , in xray_fdr_logging.cc ,such as line 56:

if (!__sanitizer::atomic_compare_exchange_strong(
         &LogFlushStatus, &Result, XRayLogFlushStatus::XRAY_LOG_FLUSHING,
         __sanitizer::memory_order_release))

currently x-ray didn't compile on windows,but this is a little step to make it build. I'm trying to build xray runtime on windows, some talks here:
http://lists.llvm.org/pipermail/llvm-dev/2017-November/119218.html

Nov 29 2017, 5:50 AM · Restricted Project

Nov 28 2017

dvyukov added inline comments to D40583: Defer StartBackgroundThread() and StopBackgroundThread() in TSan.
Nov 28 2017, 11:53 PM · Restricted Project
dvyukov added inline comments to D40583: Defer StartBackgroundThread() and StopBackgroundThread() in TSan.
Nov 28 2017, 11:52 PM · Restricted Project
dvyukov accepted D40583: Defer StartBackgroundThread() and StopBackgroundThread() in TSan.

LGTM with a nit

Nov 28 2017, 11:51 PM · Restricted Project
dvyukov accepted D40337: Support the setjmp(3) family of functions in TSan/NetBSD.
Nov 28 2017, 9:26 AM · Restricted Project
dvyukov added a comment to D40545: [sanitizer] add msvc atomic_compare_exchange_strong for sint32_t.

Where do you want to use this?
I see only 2 uses of atomic_sint32_t, at least one of which should actually use atomic_uint32_t.

Nov 28 2017, 4:52 AM · Restricted Project
dvyukov added a comment to D40337: Support the setjmp(3) family of functions in TSan/NetBSD.

I will give it a try.

Can I extract the LongJmp change and commit to the main sources now as it?

Nov 28 2017, 3:11 AM · Restricted Project
dvyukov added inline comments to D40337: Support the setjmp(3) family of functions in TSan/NetBSD.
Nov 28 2017, 2:44 AM · Restricted Project
dvyukov accepted D40341: Handle symbol renaming of sigaction for NetBSD.
Nov 28 2017, 2:31 AM · Restricted Project
dvyukov added a comment to D40341: Handle symbol renaming of sigaction for NetBSD.

This patch has been tested only on NetBSD and with asan, msan, lsan, tsan, ubsan, libfuzzer, safestack, profile.

I request for a tester on Linux as it might have impact for e.g. esan.

Nov 28 2017, 2:31 AM · Restricted Project

Nov 26 2017

dvyukov accepted D40294: Prevent Thread Exited/Joined events race.
Nov 26 2017, 10:36 AM · Restricted Project
dvyukov accepted D40457: Detect thread termination in LSan/NetBSD.
Nov 26 2017, 12:12 AM · Restricted Project
dvyukov added a comment to D40456: Enable additonal features in NetBSD.

Evgenii, do you know what's the policy for enabling these flags?

Nov 26 2017, 12:07 AM · Restricted Project

Nov 25 2017

dvyukov accepted D40382: Plug dlerror() leak for swift_demangle.
Nov 25 2017, 4:41 AM · Restricted Project

Nov 21 2017

dvyukov added inline comments to D40294: Prevent Thread Exited/Joined events race.
Nov 21 2017, 6:54 AM · Restricted Project
dvyukov accepted D40262: Correct NetBSD support in pthread_once(3)/TSan.
Nov 21 2017, 1:30 AM · Restricted Project

Nov 20 2017

dvyukov added inline comments to D40262: Correct NetBSD support in pthread_once(3)/TSan.
Nov 20 2017, 12:24 PM · Restricted Project
dvyukov accepted D40251: Add DemangleFunctionName for backtracing on NetBSD.
Nov 20 2017, 8:19 AM · Restricted Project
dvyukov accepted D40243: Handle NetBSD specific indirection of libpthread functions.
Nov 20 2017, 8:12 AM · Restricted Project
dvyukov added a comment to D40243: Handle NetBSD specific indirection of libpthread functions.

There is an open question what to do with tests. They report results with the mangled name in stack trace, instead of the regular libpthread(3) ones.

$ ./mutex                                                                    
==================
WARNING: ThreadSanitizer: data race (pid=13274)
  Write of size 4 at 0x0000014f9ec0 by thread T1 (mutexes: write M76):
    #0 Thread1(void*) /public/llvm-build/mutex.cc:36:9 (mutex+0x46e5ec)

  Previous write of size 4 at 0x0000014f9ec0 by thread T2:
    #0 Thread2(void*) /public/llvm-build/mutex.cc:42:9 (mutex+0x46e6b7)

  Location is global 'Global' of size 4 at 0x0000014f9ec0 (mutex+0x0000014f9ec0)

  Mutex M76 (0x0000014f9ec8) created at:
    #0 __libc_mutex_init /public/llvm/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:1137:3 (mutex+0x413ef3)
    #1 main /public/llvm-build/mutex.cc:66:3 (mutex+0x46e796)

  Thread T1 (tid=2, running) created by main thread at:
    #0 pthread_create /public/llvm/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:921:3 (mutex+0x412cf0)
    #1 main /public/llvm-build/mutex.cc:71:3 (mutex+0x46e7b5)

  Thread T2 (tid=3, finished) created by main thread at:
    #0 pthread_create /public/llvm/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:921:3 (mutex+0x412cf0)
    #1 main /public/llvm-build/mutex.cc:72:3 (mutex+0x46e7d4)

SUMMARY: ThreadSanitizer: data race /public/llvm-build/mutex.cc:36:9 in Thread1(void*)
==================
ThreadSanitizer: reported 1 warnings

__libc_mutex_init printed instead of pthread_mutex_init. This breaks tests that check for exact strings.

I will implement fix for tests (demangle names or change tests) in a dedicated review.

Nov 20 2017, 5:36 AM · Restricted Project
dvyukov accepted D40241: Handle NetBSD specific indirection of libpthread functions.
Nov 20 2017, 3:38 AM · Restricted Project

Nov 17 2017

dvyukov added a comment to D40159: Correct handling of the TLS/NetBSD block of the main program.

Joerg, please review.

Nov 17 2017, 12:02 AM · Restricted Project

Nov 15 2017

dvyukov accepted D40105: Implement GetTls() for NetBSD.
Nov 15 2017, 11:41 PM · Restricted Project
dvyukov added inline comments to D39935: [tsan] Fix signal chaining.
Nov 15 2017, 11:40 PM
dvyukov added a comment to D40032: [compiler-rt] Replace forkpty with posix_spawn.

I can't say that I fully understand what happens here, but I can rubber stamp LGTM if you wish.

Nov 15 2017, 12:01 AM · Restricted Project

Nov 14 2017

dvyukov added inline comments to D39935: [tsan] Fix signal chaining.
Nov 14 2017, 12:06 AM

Nov 13 2017

dvyukov accepted D39924: [PowerPC][tsan] Update tsan to handle changed memory layouts in newer kernels.
Nov 13 2017, 12:05 AM
dvyukov accepted D39935: [tsan] Fix signal chaining.

LGTM with a nit

Nov 13 2017, 12:03 AM

Nov 12 2017

dvyukov accepted D39929: [tsan] Deadly signal handler for tsan.
Nov 12 2017, 11:55 PM

Nov 8 2017

dvyukov accepted D39619: Correct atexit(3) support in TSan/NetBSD.
Nov 8 2017, 8:22 AM · Restricted Project
dvyukov added inline comments to D39619: Correct atexit(3) support in TSan/NetBSD.
Nov 8 2017, 8:01 AM · Restricted Project
dvyukov added a comment to D39619: Correct atexit(3) support in TSan/NetBSD.
Nov 8 2017, 7:59 AM · Restricted Project

Nov 7 2017

dvyukov added inline comments to D39619: Correct atexit(3) support in TSan/NetBSD.
Nov 7 2017, 11:55 PM · Restricted Project
dvyukov committed rL317587: tsan: allow usage of global vars with ctors in interceptors.
tsan: allow usage of global vars with ctors in interceptors
Nov 7 2017, 8:32 AM
dvyukov closed D39721: tsan: allow usage of global vars with ctors in interceptors.

Committed as 317587.

Nov 7 2017, 8:31 AM
dvyukov added inline comments to D39619: Correct atexit(3) support in TSan/NetBSD.
Nov 7 2017, 4:23 AM · Restricted Project
dvyukov added a comment to D39619: Correct atexit(3) support in TSan/NetBSD.

Hmm, I might be doing something incorrectly, but there is a problem with Vector. We fire the destructor for this LIFO container.. before actually calling atexit(3) functions from libc.

Nov 7 2017, 2:26 AM · Restricted Project
dvyukov created D39721: tsan: allow usage of global vars with ctors in interceptors.
Nov 7 2017, 2:22 AM

Nov 6 2017

dvyukov added a comment to D39619: Correct atexit(3) support in TSan/NetBSD.

The behavior of atexit(3) LIFO has been defined in the C standard.

Nov 6 2017, 6:30 AM · Restricted Project
dvyukov added a comment to D39619: Correct atexit(3) support in TSan/NetBSD.

No, __cxa_atexit will always reference the DSO handle. That exists even in the main executable.

Nov 6 2017, 5:47 AM · Restricted Project
dvyukov added a comment to D39619: Correct atexit(3) support in TSan/NetBSD.

Doesn't cxa_atexit call callbacks in the same order as atexit? You said that atexit is implemented by means of cxa_atexit.
As far as I remember, __cxa_atexit is called with dso=0 for destructors in main executable. If so, order of execution will depend on if the dtor is in main executable or not, which looks wrong.
Is it really necessary to use different call mechanisms? Please add a test for LIFO atexit order, if it works then we can keep the current code.

Nov 6 2017, 12:58 AM · Restricted Project
dvyukov accepted D39626: [Sanitizers] Check pthread_setcancel{state|type} interceptor arguments for != nullptr..
Nov 6 2017, 12:37 AM

Nov 3 2017

dvyukov added a comment to D38592: Update sanitizer_allocator to use new API..

So this could go away with AllocatorName returning null, but it's not an actual fix, we would just be pretending the issue is not there.
Adding @dvyukov for input.

Nov 3 2017, 3:29 AM

Oct 25 2017

dvyukov accepted D39124: Add NetBSD improvements in sanitizers.

Looks good to me. Thanks for bearing with me.

Oct 25 2017, 9:48 AM · Restricted Project
dvyukov closed D39151: [tsan] Fix warnings in tsan_interceptors.cc from expansion of variadic macros.
Oct 25 2017, 1:06 AM
dvyukov added a comment to D39151: [tsan] Fix warnings in tsan_interceptors.cc from expansion of variadic macros.

Landed in http://llvm.org/viewvc/llvm-project?view=revision&revision=316558

Oct 25 2017, 1:05 AM
dvyukov committed rL316558: [tsan] Fix warnings in tsan_interceptors.cc from expansion of variadic macros.
[tsan] Fix warnings in tsan_interceptors.cc from expansion of variadic macros
Oct 25 2017, 1:05 AM

Oct 24 2017

dvyukov added a comment to D39151: [tsan] Fix warnings in tsan_interceptors.cc from expansion of variadic macros.

I will commit this later today. Thanks.

Oct 24 2017, 10:36 PM
dvyukov accepted D39151: [tsan] Fix warnings in tsan_interceptors.cc from expansion of variadic macros.
Oct 24 2017, 10:34 PM
dvyukov added inline comments to D39124: Add NetBSD improvements in sanitizers.
Oct 24 2017, 9:26 AM · Restricted Project
dvyukov added a comment to D39124: Add NetBSD improvements in sanitizers.

Do you have commit access?

Oct 24 2017, 12:43 AM · Restricted Project
dvyukov added a comment to D39124: Add NetBSD improvements in sanitizers.

Besides the two details this generally looks good to me.

Oct 24 2017, 12:40 AM · Restricted Project
dvyukov added a comment to D39151: [tsan] Fix warnings in tsan_interceptors.cc from expansion of variadic macros.

Does the same requirement present in C++11?

Oct 24 2017, 12:27 AM

Oct 23 2017

dvyukov added inline comments to D39124: Add NetBSD improvements in sanitizers.
Oct 23 2017, 7:47 AM · Restricted Project
dvyukov added inline comments to D39124: Add NetBSD improvements in sanitizers.
Oct 23 2017, 7:36 AM · Restricted Project

Oct 21 2017

dvyukov added inline comments to D39124: Add NetBSD improvements in sanitizers.
Oct 21 2017, 12:05 AM · Restricted Project

Oct 20 2017

dvyukov added a comment to D39095: [tsan] Add Mutex annotation flag for constant-initialized __tsan_mutex_linker_init behavior.

+ http://llvm.org/viewvc/llvm-project?view=revision&revision=316210

Oct 20 2017, 5:10 AM · Restricted Project
dvyukov committed rL316210: tsan: add tests missed in r316209.
tsan: add tests missed in r316209
Oct 20 2017, 5:10 AM
dvyukov committed rL316209: [tsan] Add Mutex annotation flag for constant-initialized….
[tsan] Add Mutex annotation flag for constant-initialized…
Oct 20 2017, 5:10 AM
dvyukov closed D39095: [tsan] Add Mutex annotation flag for constant-initialized __tsan_mutex_linker_init behavior.
Oct 20 2017, 5:10 AM · Restricted Project
dvyukov accepted D39095: [tsan] Add Mutex annotation flag for constant-initialized __tsan_mutex_linker_init behavior.

Submitted in http://llvm.org/viewvc/llvm-project?view=revision&revision=316209

Oct 20 2017, 5:10 AM · Restricted Project
dvyukov added a comment to D39095: [tsan] Add Mutex annotation flag for constant-initialized __tsan_mutex_linker_init behavior.

LGTM except that ninja check-tsan fails:

Oct 20 2017, 5:05 AM · Restricted Project

Sep 28 2017

dvyukov committed rL314384: tsan: handle signals in pause call.
tsan: handle signals in pause call
Sep 28 2017, 12:33 AM

Sep 26 2017

dvyukov accepted D38244: [scudo] Scudo thread specific data refactor, part 3.
Sep 26 2017, 3:29 PM
dvyukov added a comment to D38245: [Sanitizers] Allocator: new "release memory to OS" implementation.

looks good to me

Sep 26 2017, 3:29 PM

Sep 25 2017

dvyukov accepted D38183: [scudo] Scudo thread specific data refactor, part 2.
Sep 25 2017, 5:02 AM

Sep 21 2017

dvyukov accepted D38139: [scudo] Scudo thread specific data refactor, part 1.
Sep 21 2017, 10:16 PM

Sep 20 2017

dvyukov added inline comments to D38019: [asan] Fix nested error detection.
Sep 20 2017, 1:34 AM

Sep 19 2017

dvyukov added inline comments to D38019: [asan] Fix nested error detection.
Sep 19 2017, 12:32 AM

Sep 14 2017

dvyukov committed rL313347: tsan: respect LDFLAGS when build Go test.
tsan: respect LDFLAGS when build Go test
Sep 14 2017, 11:53 PM

Sep 12 2017

dvyukov added a comment to D35555: [MIPS][TSAN] Fix test user_malloc.cc.

Or perhaps just disable this test with explanation of the problem.

Disabled with https://reviews.llvm.org/rL313069
Disabling instrumentation with attribute does not work as tsan still somehow inserts FuncEntry instrumentation.

Sep 12 2017, 11:59 PM
dvyukov accepted rL313069: [tsan] Disable user_malloc test which fails glibc 2.24.
Sep 12 2017, 11:58 PM
dvyukov added a comment to D37590: [scudo] RFC thread specific data refactoring.

It would be interesting to benchmark Android with cache per thread model as well.

As of now, Android still doesn't have ELF TLS but is using emutls for its thread_local variables, which doesn't work for us.

Sep 12 2017, 9:00 AM
dvyukov added inline comments to D37590: [scudo] RFC thread specific data refactoring.
Sep 12 2017, 1:34 AM
dvyukov added a comment to D37590: [scudo] RFC thread specific data refactoring.

The model could ultimately be specified via defines as opposed to be set in stone for a given platform (eg: we could do shared caches on Linux).

Sep 12 2017, 1:27 AM
dvyukov added a comment to D37590: [scudo] RFC thread specific data refactoring.

Looks reasonable.

Sep 12 2017, 1:26 AM
dvyukov added a comment to D35555: [MIPS][TSAN] Fix test user_malloc.cc.

Dmitry, I don't see how AllocateFromLocalPool approach can help here.
dlsym calls malloc() from the test, but it fails on instrumentations like tsan_func_entry even before reaching interceptor_malloc.

Sep 12 2017, 12:57 AM

Aug 31 2017

dvyukov committed rL312232: docs: don't say that data flow tracing interface is unstable.
docs: don't say that data flow tracing interface is unstable
Aug 31 2017, 4:04 AM

Aug 30 2017

dvyukov accepted D37306: Add NetBSD support in test/tsan/thread_name*.cc.
Aug 30 2017, 12:32 PM · Restricted Project
dvyukov accepted D37305: Add NetBSD support in tsan_interceptors.cc.
Aug 30 2017, 12:28 PM · Restricted Project
dvyukov created D37303: docs: don't say that data flow tracing interface is unstable.
Aug 30 2017, 11:58 AM

Aug 25 2017

dvyukov committed rL311776: tsan: fix darwin build.
tsan: fix darwin build
Aug 25 2017, 8:19 AM
dvyukov closed D37107: tsan: don't pass bogus PCs to __tsan_symbolize_external.
Aug 25 2017, 1:53 AM
dvyukov added a comment to D37107: tsan: don't pass bogus PCs to __tsan_symbolize_external.

Submitted in 311768.

Aug 25 2017, 1:53 AM
dvyukov committed rL311768: tsan: don't pass bogus PCs to __tsan_symbolize_external.
tsan: don't pass bogus PCs to __tsan_symbolize_external
Aug 25 2017, 1:53 AM
dvyukov added inline comments to D37107: tsan: don't pass bogus PCs to __tsan_symbolize_external.
Aug 25 2017, 1:53 AM
dvyukov updated the diff for D37107: tsan: don't pass bogus PCs to __tsan_symbolize_external.
Aug 25 2017, 1:53 AM

Aug 24 2017

dvyukov added a comment to D37107: tsan: don't pass bogus PCs to __tsan_symbolize_external.

I am open to suggestions. This is total mess.

Aug 24 2017, 6:55 AM
dvyukov created D37107: tsan: don't pass bogus PCs to __tsan_symbolize_external.
Aug 24 2017, 6:51 AM

Aug 8 2017

dvyukov added a comment to D36465: [RFC] Change cmp instrumentation to distinguish comparisons with const operands.
In D36465#835650, @kcc wrote:

I am fine with breaking the API. Whoever uses this API will need to add a tiny bit of code to work with the new compiler (and that code will be compatible with the old version).
It's better to break the API this way than to introduce the flags or weak aliases, etc

Please update the documentation in this patch. (mention that these functions are emitted by clang >= 2017-08-XX)

Make sure to run 'ninja check-fuzzer'. Most likely it will break due to the API change, fix it in libFuzzer (in a simple way, by calling __sanitizer_cov_trace_cmpN)

Find all uses of __sanitizer_cov_trace_cmp1 in projects/compiler-rt/lib/sanitizer_common and update those files.

Aug 8 2017, 11:13 AM
dvyukov added a comment to D36465: [RFC] Change cmp instrumentation to distinguish comparisons with const operands.

Kostya, Dima,

Do we need to put this code behind a flag (probably yes, if we don't want to break the API for the existing users)?
Any other comments?

Aug 8 2017, 7:51 AM

Aug 1 2017

dvyukov accepted D36192: [tsan] Fix format string in WriteMemoryProfile.
Aug 1 2017, 11:08 PM · Restricted Project

Jul 23 2017

dvyukov accepted D35690: [Sanitizers] TSan allocator set errno on failure..
Jul 23 2017, 12:58 AM