Page MenuHomePhabricator

dvyukov (Dmitry Vyukov)
User

Projects

User does not belong to any projects.

User Details

User Since
Dec 6 2012, 2:31 AM (354 w, 4 d)

Recent Activity

Yesterday

dvyukov added a comment to D28596: [compiler-rt] General definition for weak functions..

Turns out this broke an important part of our internal integration because sanitizer::OnPrint become OnPrint, so existing hook stopped working. We are clearly missing some tests.
But exporting and calling a global extern "C" OnPrint does not look OK. All functions need to be either extern "C" and
sanitizer_ prefixed, or in __sanitizer:: namespace.

Sun, Sep 22, 12:31 AM · Restricted Project
dvyukov added reviewers for D28596: [compiler-rt] General definition for weak functions.: vitalybuka, morehouse.
Sun, Sep 22, 12:26 AM · Restricted Project

Wed, Sep 18

dvyukov committed rGd97865e530df: tsan: allow the Go runtime to return multiple stack frames for a single PC (authored by dvyukov).
tsan: allow the Go runtime to return multiple stack frames for a single PC
Wed, Sep 18, 2:18 AM
dvyukov closed D67671: compiler-rt/lib/tsan: allow the Go runtime to return multiple stack frames for a single PC.
Wed, Sep 18, 2:17 AM · Restricted Project, Restricted Project
dvyukov accepted D67671: compiler-rt/lib/tsan: allow the Go runtime to return multiple stack frames for a single PC.

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

Wed, Sep 18, 2:17 AM · Restricted Project, Restricted Project
dvyukov committed rL372205: tsan: allow the Go runtime to return multiple stack frames for a single PC.
tsan: allow the Go runtime to return multiple stack frames for a single PC
Wed, Sep 18, 2:16 AM

Tue, Sep 17

dvyukov added a comment to D67671: compiler-rt/lib/tsan: allow the Go runtime to return multiple stack frames for a single PC.

Besides the nits, are you sure we reconstruct the list in the right order? :)
Did you test it with the Go counterpart? There is that buildgo.sh script that builds new syso file, which you can copy into Go runtime/race.
It would also be nice to have an output test for inlined frames here:
https://github.com/golang/go/blob/master/src/runtime/race/output_test.go
It needs to go with the updated syso files, but you could use it for testing now.
Fingers crossed nothing broke since last syso update.

Tue, Sep 17, 11:53 AM · Restricted Project, Restricted Project

Mon, Sep 16

dvyukov accepted D66885: [TSan] Add read/write range interface functions with PC.

Generally looks good to me.

Mon, Sep 16, 6:31 AM · Restricted Project, Restricted Project

Thu, Aug 29

dvyukov added a comment to D66885: [TSan] Add read/write range interface functions with PC.

In this new test, I see the same issue related to race on stack variables as reported here:
https://github.com/google/sanitizers/issues/1134

Thu, Aug 29, 11:39 AM · Restricted Project, Restricted Project

Wed, Aug 28

dvyukov added a comment to D66885: [TSan] Add read/write range interface functions with PC.

Re tests. Check test/tsan/ dir, e.g. simple_race.c, stack_race.cc, test/tsan/unaligned_norace.cc. There are not too hard to write, we just need to check it builds, detects a race on the annotation and the PC is used in the stack.

Wed, Aug 28, 11:09 AM · Restricted Project, Restricted Project
dvyukov added a comment to D66885: [TSan] Add read/write range interface functions with PC.

Thanks for the background. Good to know.

Wed, Aug 28, 11:09 AM · Restricted Project, Restricted Project
dvyukov added a reviewer for D66885: [TSan] Add read/write range interface functions with PC: eugenis.
Wed, Aug 28, 11:03 AM · Restricted Project, Restricted Project
dvyukov added a comment to D66885: [TSan] Add read/write range interface functions with PC.

Who are "we"? And you would prefer to call them where? ;)
Also, tests.

Wed, Aug 28, 8:13 AM · Restricted Project, Restricted Project

Jul 17 2019

dvyukov added a comment to D64299: Make ~mutex and ~condition_variable trivial with Bionic pthreads.

Thanks for bringing this up. Indeed this change really hurts TSAN.
I'll look for ways to work around this issue.

I think we could have clang provide an annotation for mutex types that will inject calls to the tsan runtime when a mutex gets created or destroyed.

On a separate note, what kinds of resources leaks are you imagining?

Jul 17 2019, 10:49 PM
dvyukov added a comment to D64299: Make ~mutex and ~condition_variable trivial with Bionic pthreads.

This feels like the right trade-off.

TSan should be fine with a mutex that is never destroyed, but it will not be able to catch lock-after-destroy bugs on such mutex obviously.
@dvyukov

Effectively pthread_mutex_destroy is not trivial under tsan so, yes, there will be a number of negative consequences:

  • no lock-after-destroy races
  • no races between lock/unlock and a subsequent destory
  • no racy use-after-free detection for destroy vs free
  • incorrect stack trace for a mutex that happened to reuse the address later
  • resource leaks for mutexes
  • no reporting of unlock of locked mutex
  • no auto-unlock for destroyed mutexes, which will look like the thread is taking infinite number of locks recursively, which will quickly check-fail in deadlock detector

Why is that not an issue for pthread mutexes with static initialization and no destruction?

Jul 17 2019, 10:46 PM
dvyukov added a comment to D64299: Make ~mutex and ~condition_variable trivial with Bionic pthreads.

This feels like the right trade-off.

TSan should be fine with a mutex that is never destroyed, but it will not be able to catch lock-after-destroy bugs on such mutex obviously.
@dvyukov

Jul 17 2019, 12:19 AM

Jul 4 2019

dvyukov accepted D64092: [TSan] Improve handling of stack pointer mangling in {set,long}jmp, pt.8.
Jul 4 2019, 11:25 AM · Restricted Project, Restricted Project
dvyukov accepted D63946: [TSan] Improve handling of stack pointer mangling in {set,long}jmp, pt.4.

Nice!

Jul 4 2019, 11:24 AM · Restricted Project, Restricted Project
dvyukov accepted D64022: [TSan] Improve handling of stack pointer mangling in {set,long}jmp, pt.5.

Everything that deletes code LGTM :)

Jul 4 2019, 11:24 AM · Restricted Project, Restricted Project

Jul 2 2019

dvyukov accepted D63764: [Sanitizers] Remove obsolete OpenFile from sanitizer_solaris.cc.

Then looks like the right thing to do.
Do you have commit access? Or you want me to submit this?

Jul 2 2019, 1:05 AM · Restricted Project, Restricted Project
dvyukov added a comment to D63764: [Sanitizers] Remove obsolete OpenFile from sanitizer_solaris.cc.

Are you sure it's unused? I see several uses of this function:

Jul 2 2019, 12:48 AM · Restricted Project, Restricted Project

Jul 1 2019

dvyukov accepted D64023: [TSan] Improve handling of stack pointer mangling in {set,long}jmp, pt.6.

Rubber stamp LGTM, if you want a real review please ask somebody else. But if you are sure it's good and covered by tests, submit.

Jul 1 2019, 10:12 PM · Restricted Project, Restricted Project
dvyukov accepted D64050: [TSan] Improve handling of stack pointer mangling in {set,long}jmp, pt.7.

Is there anything else to review at the moment? Want to make sure I did not lost track of things.

Jul 1 2019, 10:07 PM · Restricted Project, Restricted Project
dvyukov accepted D63944: [TSan] Improve handling of stack pointer mangling in {set,long}jmp, pt.3.

Looks good (if it does not break anything :))

Jul 1 2019, 2:21 AM · Restricted Project, Restricted Project
dvyukov accepted D63942: [TSan] Improve handling of stack pointer mangling in {set,long}jmp, pt.2.

Looks good (if it does not break anything :))

Jul 1 2019, 2:19 AM · Restricted Project, Restricted Project
dvyukov added a comment to D60981: [TSan] Improve handling of stack pointer mangling in {set,long}jmp, pt.1.

@dvyukov: I finally have a chance to continue working on this. I hope you are still onboard?

Jul 1 2019, 2:18 AM · Restricted Project, Restricted Project

Jun 24 2019

dvyukov added a comment to D59963: [clang-tidy] Add a module for the Linux kernel..

Re more checks. I guess we can borrow some from the existing checkers:
https://www.kernel.org/doc/html/v4.12/dev-tools/sparse.html
https://bottest.wiki.kernel.org/coccicheck
https://lwn.net/Articles/752408/
https://lwn.net/Articles/691882/

Jun 24 2019, 7:40 AM · Restricted Project, Restricted Project, Restricted Project
dvyukov added a comment to D59963: [clang-tidy] Add a module for the Linux kernel..

I assume you tried to run it on the kernel. Please post the current output somewhere.

Jun 24 2019, 7:37 AM · Restricted Project, Restricted Project, Restricted Project

May 22 2019

dvyukov added a comment to D61708: [TSan] Support `ignore_noninstrumented_modules` on Linux.

If you mean that it will work only for tsan now, I guess it is fine. Other sanitizers can add it when they need it.

May 22 2019, 12:09 AM · Restricted Project, Restricted Project
dvyukov added a comment to D61708: [TSan] Support `ignore_noninstrumented_modules` on Linux.

There is also dlinfo which returns some info about a shared object. I don't know if it may help or not, just pointing out. We need just any mark that the compiler can leave in the shared object and runtime then can detect as easily as possible.

May 22 2019, 12:08 AM · Restricted Project, Restricted Project

May 20 2019

dvyukov added a comment to D61708: [TSan] Support `ignore_noninstrumented_modules` on Linux.

I am still a bit worried by the amount of complex code we have for this. I wonder if there is a simpler way to do this. Have you considered any other alternatives? Could we emit some symbol in the library and then use dlsym on it? Or maybe emit some section and then iterate over section names only?

May 20 2019, 10:21 PM · Restricted Project, Restricted Project

May 8 2019

dvyukov added a comment to D61708: [TSan] Support `ignore_noninstrumented_modules` on Linux.

Evgenii, maybe you can think of some simpler magical way to understand if a module is instrumented or not?

May 8 2019, 10:24 PM · Restricted Project, Restricted Project
dvyukov edited reviewers for D61708: [TSan] Support `ignore_noninstrumented_modules` on Linux, added: vitalybuka, eugenis; removed: samsonov.
May 8 2019, 10:22 PM · Restricted Project, Restricted Project

Apr 23 2019

dvyukov accepted D60981: [TSan] Improve handling of stack pointer mangling in {set,long}jmp, pt.1.

JmpBufGarbageCollect uses <= on sp values to detect bufs that are no longer active. But as far as I understand we still will able to do this, right?

Apr 23 2019, 5:12 AM · Restricted Project, Restricted Project

Apr 9 2019

dvyukov added a comment to D60347: [TSan][libdispatch] Replace CFRunLoop with dispatch_semaphore, pt. 1.

As long as the tests pass, it's fine with me :)

Apr 9 2019, 10:16 AM · Restricted Project, Restricted Project

Mar 14 2019

dvyukov accepted D59334: [TSan][libdispatch] Enable linking and running of tests on Linux.

I don't see any problems (because I don't understand cmake), so I am signing off :)

Mar 14 2019, 11:40 PM · Restricted Project, Restricted Project

Mar 7 2019

dvyukov accepted D59113: [TSan] Initialize libdispatch interceptors if necessary.
Mar 7 2019, 10:05 PM · Restricted Project, Restricted Project

Mar 6 2019

dvyukov accepted D59067: [TSan][Linux] Fix libdispatch interception macros compilation errors.
Mar 6 2019, 10:15 PM · Restricted Project, Restricted Project
dvyukov accepted D59037: [Sanitizer] Add 'dispatch' feature to be used in compiler-rt tests.
Mar 6 2019, 10:14 PM · Restricted Project, Restricted Project
dvyukov accepted D59047: [NFC][TSan] Add libdispatch tests for non-Darwin platforms.
Mar 6 2019, 10:13 PM · Restricted Project, Restricted Project
dvyukov accepted D58935: [tsan] Support interception of libdispatch on Linux.

I should have read it better!

Mar 6 2019, 2:23 AM · Restricted Project, Restricted Project

Mar 4 2019

dvyukov added a comment to D58935: [tsan] Support interception of libdispatch on Linux.

I don't mind merging this, but what's the usage/test story here? There are 30+ tests in test/Darwin/gcd-* but they don't run on linux.
Do you intend to do some further development of this support? I just afraid that most users won't be able to use it because it's not enabled, and the ones that will build own compiler will find it broken.

Mar 4 2019, 10:42 PM · Restricted Project, Restricted Project

Feb 25 2019

dvyukov added a comment to D58110: Support fiber API on macOS.

Kuba, please submit this. I can't test/build this.

Feb 25 2019, 12:08 AM · Restricted Project, Restricted Project

Feb 13 2019

dvyukov updated subscribers of D54889: Fiber support for thread sanitizer.

CC @Yi-Hong.Lyu

Feb 13 2019, 8:46 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

I see a similar failure was already reported:
https://reviews.llvm.org/D54889#1394632
There was no fix for it, right? Or did I forgot to squash something else?

Feb 13 2019, 8:45 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.
  • Forwarded message ---------

From: Yi-Hong Lyu via Phabricator <reviews@reviews.llvm.org>
Date: Wed, Feb 13, 2019 at 5:33 PM
Subject: [Diffusion] rL353817: tsan: add fiber support

Feb 13 2019, 8:42 AM · Restricted Project, Restricted Project
dvyukov committed rG76e961207bd1: tsan: add fiber support (authored by dvyukov).
tsan: add fiber support
Feb 13 2019, 5:21 AM
dvyukov closed D58171: Fix thread sanitizer on aarch64.

This is submitted as part of 353947

Feb 13 2019, 5:21 AM · Restricted Project, Restricted Project
dvyukov committed rCRT353947: .
Feb 13 2019, 5:21 AM
dvyukov committed rL353947: .
Feb 13 2019, 5:21 AM
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Resubmitted in 353947 with 2 fixes squashed.

Feb 13 2019, 5:21 AM · Restricted Project, Restricted Project
dvyukov accepted D58171: Fix thread sanitizer on aarch64.

Looks good to me.

Feb 13 2019, 4:36 AM · Restricted Project, Restricted Project

Feb 12 2019

dvyukov added a comment to D58110: Support fiber API on macOS.

Kuba, please take a look. This mostly touches Mac-specific files. I can't test this.

Feb 12 2019, 2:39 AM · Restricted Project, Restricted Project
dvyukov committed rG19e41fb0ca4d: tsan: update check_analyze.sh (authored by dvyukov).
tsan: update check_analyze.sh
Feb 12 2019, 2:18 AM
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

FTR updated check_analyze.sh in http://llvm.org/viewvc/llvm-project?view=revision&revision=353820

Feb 12 2019, 2:18 AM · Restricted Project, Restricted Project
dvyukov committed rCRT353820: tsan: update check_analyze.sh.
tsan: update check_analyze.sh
Feb 12 2019, 2:18 AM
dvyukov committed rL353820: tsan: update check_analyze.sh.
tsan: update check_analyze.sh
Feb 12 2019, 2:18 AM
dvyukov closed D54889: Fiber support for thread sanitizer.

Committed in:
http://llvm.org/viewvc/llvm-project?view=revision&revision=353817

Feb 12 2019, 2:14 AM · Restricted Project, Restricted Project
dvyukov committed rG6e7089ad4036: tsan: add fiber support (authored by dvyukov).
tsan: add fiber support
Feb 12 2019, 2:12 AM
dvyukov committed rCRT353817: tsan: add fiber support.
tsan: add fiber support
Feb 12 2019, 2:12 AM
dvyukov accepted D54889: Fiber support for thread sanitizer.
Feb 12 2019, 2:12 AM · Restricted Project, Restricted Project
dvyukov committed rL353817: tsan: add fiber support.
tsan: add fiber support
Feb 12 2019, 2:12 AM
dvyukov added inline comments to D58108: [sanitizer]: fix warnings reported by SVACE static analyzer..
Feb 12 2019, 1:25 AM · Restricted Project, Restricted Project
dvyukov committed rGca524b19c152: tsan: Introduce in_symbolizer() function for Thread sanitizer (authored by dvyukov).
tsan: Introduce in_symbolizer() function for Thread sanitizer
Feb 12 2019, 12:12 AM
dvyukov committed rCRT353805: tsan: Introduce in_symbolizer() function for Thread sanitizer.
tsan: Introduce in_symbolizer() function for Thread sanitizer
Feb 12 2019, 12:11 AM
dvyukov committed rL353805: tsan: Introduce in_symbolizer() function for Thread sanitizer.
tsan: Introduce in_symbolizer() function for Thread sanitizer
Feb 12 2019, 12:11 AM
dvyukov closed D58104: Introduce in_symbolizer() function for Thread sanitizer.

Submitted in 353805.

Feb 12 2019, 12:10 AM · Restricted Project, Restricted Project
dvyukov accepted D58104: Introduce in_symbolizer() function for Thread sanitizer.

Perfect! Thanks!
Testing and submitting.

Feb 12 2019, 12:08 AM · Restricted Project, Restricted Project

Feb 11 2019

dvyukov added a comment to D54889: Fiber support for thread sanitizer.

However, for thread initialization we rely on the fact that pthread's thread entry function (start_thread) calls _setjmp which we intercept. If start_thread does not call _setjmp then we risk to hit NULL cur_thread in secondary threads. I think we need to add cur_thread_init also to:

  1. SCOPED_INTERCEPTOR_RAW (this will ensure that if start_thread calls any intercepted libc function, we will init at that point)

There is a lot if interceptors that do

if (cur_thread()->in_symbolizer)

before SCOPED_INTERCEPTOR_RAW. What to do with them?

Feb 11 2019, 6:47 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

The change is now a very good shape.

Feb 11 2019, 4:05 AM · Restricted Project, Restricted Project
dvyukov added a comment to D57876: Implement pthread_exit() interceptor for Thread sanitizer.

I've seen some fixes has landed over the weekend. Is this fixed now? Or some breakages still remain?

macOS is fixed.
Test on ppc64 is disabled — pthread_exit does not work there without any interceptors.

Feb 11 2019, 2:02 AM · Restricted Project, Restricted Project
dvyukov added a comment to D57876: Implement pthread_exit() interceptor for Thread sanitizer.

I've seen some fixes has landed over the weekend. Is this fixed now? Or some breakages still remain?

Feb 11 2019, 1:33 AM · Restricted Project, Restricted Project
dvyukov added a comment to rL353385: tsan: Implement pthread_exit() interceptor for Thread sanitizer.

Hi Yi-Hong,
Let's move the discussion to https://reviews.llvm.org/D57876 because there is already some.

Feb 11 2019, 1:32 AM

Feb 8 2019

dvyukov added a comment to D57876: Implement pthread_exit() interceptor for Thread sanitizer.

One thing that I noticed is that pthread_exit is a noreturn function and SCOPED_TSAN_INTERCEPTOR creates a local object with destructor. At the very least this leads to confusing code where readers assumption is that the destructor will run, but it will not.
Perhaps we should try to remove the SCOPED_TSAN_INTERCEPTOR entirely as the CHECK that we want to add here does not need it.

Feb 8 2019, 12:22 AM · Restricted Project, Restricted Project
dvyukov added a comment to D57876: Implement pthread_exit() interceptor for Thread sanitizer.
  • Forwarded message ---------

From: Alex L
Date: Fri, Feb 8, 2019 at 1:17 AM
Subject: Re: [compiler-rt] r353385 - tsan: Implement pthread_exit() interceptor for Thread sanitizer

Feb 8 2019, 12:13 AM · Restricted Project, Restricted Project

Feb 7 2019

dvyukov added a comment to D54889: Fiber support for thread sanitizer.

To clarify the graph: it's difference in execution time in percents as compared to the current HEAD. I.e. -4 means that fibers are 4% slower than the current HEAD.
1w means mop.cc benchmark with 1-byte write accesses; 4r - 4-byte read accesses. ee is func_entry_exit.cc benchmark.

Feb 7 2019, 9:37 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Did another round of benchmarking of this change on the current HEAD using these 2 benchmarks:
https://github.com/llvm-mirror/compiler-rt/blob/master/lib/tsan/benchmarks/mop.cc
https://github.com/llvm-mirror/compiler-rt/blob/master/lib/tsan/benchmarks/func_entry_exit.cc

Feb 7 2019, 9:33 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Current code runs in 7.16s
This change -- 6.23s
This change + cur_thread_fast returning cur_thread_placeholder -- 7.01s
I also tried this change + FuncEntry using cur_thread_fast -- 6.20s

But if I do:

INLINE ThreadState *cur_thread_fast() {
  ThreadState* thr;
  __asm__("": "=a"(thr): "a"(&cur_thread_placeholder[0]));
  return thr;
}

(which is a dirty trick to force compiler to cache address of the tls object in a register) then the program runs 5.94s -- faster than any other options as it takes advantage of both no indirection and faster instructions.

Feb 7 2019, 6:09 AM · Restricted Project, Restricted Project
dvyukov committed rGbdfba86047cd: tsan: add more benchmarks (authored by dvyukov).
tsan: add more benchmarks
Feb 7 2019, 6:05 AM
dvyukov committed rCRT353407: tsan: add more benchmarks.
tsan: add more benchmarks
Feb 7 2019, 6:04 AM
dvyukov committed rL353407: tsan: add more benchmarks.
tsan: add more benchmarks
Feb 7 2019, 6:04 AM
dvyukov closed D57882: Optimize performance of Thread sanitizer memory access functions.

Committed in 353401
http://llvm.org/viewvc/llvm-project?view=revision&revision=353401

Feb 7 2019, 4:44 AM · Restricted Project, Restricted Project
dvyukov committed rGfddaf1f369a1: tsan: Optimize performance of Thread sanitizer memory access functions (authored by dvyukov).
tsan: Optimize performance of Thread sanitizer memory access functions
Feb 7 2019, 4:44 AM
dvyukov committed rCRT353401: tsan: Optimize performance of Thread sanitizer memory access functions.
tsan: Optimize performance of Thread sanitizer memory access functions
Feb 7 2019, 4:43 AM
dvyukov committed rL353401: tsan: Optimize performance of Thread sanitizer memory access functions.
tsan: Optimize performance of Thread sanitizer memory access functions
Feb 7 2019, 4:43 AM
dvyukov accepted D57882: Optimize performance of Thread sanitizer memory access functions.
Feb 7 2019, 4:40 AM · Restricted Project, Restricted Project
dvyukov committed rGbaf2f35ec4c5: sanitizers: Introduce ThreadType enum (authored by dvyukov).
sanitizers: Introduce ThreadType enum
Feb 7 2019, 3:02 AM
dvyukov closed D57839: Introduce ThreadType enum.
Feb 7 2019, 3:01 AM · Restricted Project, Restricted Project
dvyukov added a comment to D57839: Introduce ThreadType enum.

Committed in 353390
http://llvm.org/viewvc/llvm-project?view=revision&revision=353390

Feb 7 2019, 3:01 AM · Restricted Project, Restricted Project
dvyukov committed rL353390: sanitizers: Introduce ThreadType enum.
sanitizers: Introduce ThreadType enum
Feb 7 2019, 3:01 AM
dvyukov committed rCRT353390: sanitizers: Introduce ThreadType enum.
sanitizers: Introduce ThreadType enum
Feb 7 2019, 3:01 AM
dvyukov accepted D57839: Introduce ThreadType enum.
Feb 7 2019, 3:00 AM · Restricted Project, Restricted Project
dvyukov committed rG17132b62e037: tsan: Implement pthread_exit() interceptor for Thread sanitizer (authored by dvyukov).
tsan: Implement pthread_exit() interceptor for Thread sanitizer
Feb 7 2019, 2:46 AM
dvyukov closed D57876: Implement pthread_exit() interceptor for Thread sanitizer.

Committed in 353385
http://llvm.org/viewvc/llvm-project?view=revision&revision=353385

Feb 7 2019, 2:46 AM · Restricted Project, Restricted Project
dvyukov committed rCRT353385: tsan: Implement pthread_exit() interceptor for Thread sanitizer.
tsan: Implement pthread_exit() interceptor for Thread sanitizer
Feb 7 2019, 2:46 AM
dvyukov committed rL353385: tsan: Implement pthread_exit() interceptor for Thread sanitizer.
tsan: Implement pthread_exit() interceptor for Thread sanitizer
Feb 7 2019, 2:45 AM
dvyukov accepted D57876: Implement pthread_exit() interceptor for Thread sanitizer.
Feb 7 2019, 2:43 AM · Restricted Project, Restricted Project

Feb 6 2019

dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Going forward I think we should get in all unrelated/preparatory changed first: thread type (creates lots of diffs), pthread_exit interceptor/test and spot optimizations to memory access functions.

Feb 6 2019, 7:07 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Current code runs in 7.16s
This change -- 6.23s
This change + cur_thread_fast returning cur_thread_placeholder -- 7.01s
I also tried this change + FuncEntry using cur_thread_fast -- 6.20s

Feb 6 2019, 6:53 AM · Restricted Project, Restricted Project

Feb 5 2019

dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Also benchmarked function entry/exit using the following benchmark:

Feb 5 2019, 7:20 AM · Restricted Project, Restricted Project