dvyukov (Dmitry Vyukov)
User

Projects

User does not belong to any projects.

User Details

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

Recent Activity

Today

dvyukov added inline comments to D33286: Don't require ThreadState to be contained within tls on all platforms.
Wed, May 24, 2:04 AM
dvyukov added a comment to D33454: [sanitizer] Change the 32-bit Primary AllocateRegion to reduce fragmentation.

looks good to me

Wed, May 24, 1:41 AM
dvyukov added a comment to D33454: [sanitizer] Change the 32-bit Primary AllocateRegion to reduce fragmentation.

I am not certain about the Windows impact of this change

Wed, May 24, 1:41 AM
dvyukov added a comment to D33454: [sanitizer] Change the 32-bit Primary AllocateRegion to reduce fragmentation.

FWIW I've solved a similar problem in tcmalloc by trimming blocks either on left or on right. Namely, if heap grows up we trim on right; if heap grows down we trim on left. But I don't see how it is better than this solution.

Wed, May 24, 1:37 AM
dvyukov added inline comments to D33325: [sanitizer] Avoid possible deadlock in child process after fork.
Wed, May 24, 1:19 AM · Restricted Project

Yesterday

dvyukov added a comment to D33286: Don't require ThreadState to be contained within tls on all platforms.

I think that's because we use _shadow_ memory to store pointer to ThreadState. See cur_thread in tsan_platform_mac.cc. We probably need to skip that slot or something.

Tue, May 23, 8:17 AM
dvyukov added inline comments to D33325: [sanitizer] Avoid possible deadlock in child process after fork.
Tue, May 23, 7:32 AM · Restricted Project
dvyukov added a comment to D33325: [sanitizer] Avoid possible deadlock in child process after fork.

I don't completely understand this. allocator_fork_no_hang.cc is broken and deserves deadlocking. Why are we trying to fix this program only under sanitizers rather than detecting and reporting the bug? Sanitizers are meant to be less forgiving than production environment. Why are we trying to conceal the bug?

Yes, the testcase deserves deadlocking (malloc is not async signal safe). And the actual bug is reported here: https://bugzilla.gnome.org/show_bug.cgi?id=738620.
The motivation for "fixing" this in sanitizers is that most of modern allocators (Glibc, tcmalloc, jemalloc) are actually fork safe, so why not to do the same in sanitizers. And despite the fact that calling malloc after multi-threaded fork is not allowed, many people still would expect their code to work (since it works with Glibc/tcmalloc/jemalloc etc).

Tue, May 23, 7:29 AM · Restricted Project
dvyukov added a comment to D33325: [sanitizer] Avoid possible deadlock in child process after fork.

I don't completely understand this. allocator_fork_no_hang.cc is broken and deserves deadlocking. Why are we trying to fix this program only under sanitizers rather than detecting and reporting the bug? Sanitizers are meant to be less forgiving than production environment. Why are trying to conceal the bug?

Tue, May 23, 6:18 AM · Restricted Project
dvyukov accepted D33286: Don't require ThreadState to be contained within tls on all platforms.

Thanks!

Tue, May 23, 12:22 AM

Mon, May 22

dvyukov added a comment to D33286: Don't require ThreadState to be contained within tls on all platforms.

Yes, please do this only for Darwin. These things are extremely fragile, it's nice to be able to rely at least on some things. If we change it to if, it will silently break on other platforms and we will not notice.
You can either move some code to platform* files, or merely provide a flag in platform* files and use it here.

Mon, May 22, 12:59 AM

Wed, May 10

dvyukov added a comment to D33007: [scudo] Use our own combined allocator.

Looks fine to me. Aleksey, do you want to take a look?

Wed, May 10, 2:30 PM

Mon, May 8

dvyukov added inline comments to D32971: [scudo] CRC32 optimizations.
Mon, May 8, 1:50 PM
dvyukov added inline comments to D32971: [scudo] CRC32 optimizations.
Mon, May 8, 12:54 PM
dvyukov added inline comments to D32971: [scudo] CRC32 optimizations.
Mon, May 8, 12:47 PM
dvyukov added inline comments to D32971: [scudo] CRC32 optimizations.
Mon, May 8, 12:04 PM

Fri, May 5

dvyukov edited reviewers for D32895: [ASAN] Insert call to __asan_init and load of dynamic shadow address in correct order, added: alekseyshl; removed: dvyukov.
Fri, May 5, 7:29 AM · Restricted Project

Wed, May 3

dvyukov accepted D31630: [tsan] Detect races on modifying accesses in Swift code.

Thanks!
I think this now provides a solid foundation for future extensions.

Wed, May 3, 4:17 AM · Restricted Project

Tue, May 2

dvyukov added a comment to D31395: [Asan] Disable inline instrumentation for MMU-less targets.

One more thing: now that D31592 is landed, would you mind if we do the same for Tsan?

Tue, May 2, 9:46 AM · Restricted Project
dvyukov added a comment to D31395: [Asan] Disable inline instrumentation for MMU-less targets.

Dmitry, with your permission I'm going to update and commit this patch as it seems to be useful regardless of which way we support sanitizers on MMU-less platforms.

Tue, May 2, 9:40 AM · Restricted Project
dvyukov committed rL301927: tsan: allow fast large MemoryRangeSet on non-Windows Go.
tsan: allow fast large MemoryRangeSet on non-Windows Go
Tue, May 2, 8:28 AM
dvyukov accepted D32705: [compiler-rt] move tsan's Android __get_tls() to sanitizer_common.

Thanks!

Tue, May 2, 8:07 AM
dvyukov added inline comments to D32705: [compiler-rt] move tsan's Android __get_tls() to sanitizer_common.
Tue, May 2, 4:56 AM

Mon, May 1

dvyukov added a comment to D31593: [Asan] Introduce the concept of physical shadow memory.

This patch introduces a class of shadow pointers designed to be the interface to physical shadow memory. The idea behind shadow pointers is to encapsulate the physical memory mechanics so that:

  • sequential accesses to the same shadow page do not cause extra virtual-to-physical address translations, thus providing acceptable performance in the MMU-less mode and
  • sanitizer developers are not forced to take care of the organization of physical memory when dealing with shadow accesses.

    This patch intentionally includes (not-yet-committed) D31395 so one could apply and test it if necessary. Once generally accepted, I will remove those common parts and update the patch.
Mon, May 1, 3:58 AM · Restricted Project
dvyukov committed rL301795: tsan: support linker init flag in __tsan_mutex_destroy.
tsan: support linker init flag in __tsan_mutex_destroy
Mon, May 1, 3:14 AM

Sat, Apr 29

dvyukov added inline comments to D32649: [scudo] Add Android support.
Sat, Apr 29, 2:07 PM
dvyukov accepted D32382: [tsan] Track external tags in thread traces.

One last thing. Otherwise LGTM.

Sat, Apr 29, 12:52 PM · Restricted Project
dvyukov added inline comments to D32649: [scudo] Add Android support.
Sat, Apr 29, 9:39 AM

Thu, Apr 27

dvyukov accepted D32440: [scudo] Move thread local variables into their own files.

LGTM on my side, but wait for Aleksey if he has more comments

Thu, Apr 27, 10:17 AM
dvyukov added inline comments to D32440: [scudo] Move thread local variables into their own files.
Thu, Apr 27, 3:25 AM

Wed, Apr 26

dvyukov added a comment to D32440: [scudo] Move thread local variables into their own files.

otherwise looks good

Wed, Apr 26, 11:59 AM

Tue, Apr 25

dvyukov added a comment to D31630: [tsan] Detect races on modifying accesses in Swift code.

The memory/threading model of Swift defines races in terms of accesses: Starting a new "modifying" access requires that there are no outstanding accesses. And "access" here means the formal duration over which the variable is accessed, e.g. the whole function call for inout arguments. This is all pretty new and still being worked on: https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md.

Then let's register report header for external tags.

What do you mean by that? Can you explain?

Tue, Apr 25, 9:43 AM · Restricted Project
dvyukov added a comment to D31630: [tsan] Detect races on modifying accesses in Swift code.

ThreadSanitizer: race on Swift array
ThreadSanitizer: race on Swift map

Unfortunately, we won't be able to tell the type of the variable (at least not now). I've updated the patch to say "race on Swift variable", but that's not really exact and it's not describing the problem well. Swift is getting exact threading rules that are very different from C/C++ and I'm trying to focus on making the reports readable and understandable by Swift users.

Is there a way we could still special-case the Swift reports? I understand the desire to keep the API generic, but I think we need to make sure the users understand the report. E.g. "Swift access race" much better describes what the problem is, and users words that define the Swift threading model.

Humm... what is so special about Swift? Isn't it that concurrent accesses to some objects are a bug? I would expect that it is, and then it's no different from C/C++ variables, C++ containers, Go variables and containers, Java containers, file descriptors and everything else.

I don't understand why saying race or data race on something is confusing or not understand-able. What's ambiguous/obscure/wrong about it?
On the other hand I have problems understanding meaning of "Swift access race". Does it mean "race during access to a Swift object"? If so it's semantically equivalent to "race on Swift object".

The memory/threading model of Swift defines races in terms of accesses: Starting a new "modifying" access requires that there are no outstanding accesses. And "access" here means the formal duration over which the variable is accessed, e.g. the whole function call for inout arguments. This is all pretty new and still being worked on: https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md.

Tue, Apr 25, 9:20 AM · Restricted Project
dvyukov added a comment to D31630: [tsan] Detect races on modifying accesses in Swift code.

ThreadSanitizer: race on Swift array
ThreadSanitizer: race on Swift map

Unfortunately, we won't be able to tell the type of the variable (at least not now). I've updated the patch to say "race on Swift variable", but that's not really exact and it's not describing the problem well. Swift is getting exact threading rules that are very different from C/C++ and I'm trying to focus on making the reports readable and understandable by Swift users.

Is there a way we could still special-case the Swift reports? I understand the desire to keep the API generic, but I think we need to make sure the users understand the report. E.g. "Swift access race" much better describes what the problem is, and users words that define the Swift threading model.

Tue, Apr 25, 5:35 AM · Restricted Project
dvyukov added a comment to D31630: [tsan] Detect races on modifying accesses in Swift code.

Also, could swift runtime register a tag at startup? Or performance overhead is a concern?

It's quite hard to make the runtime call the registration at process startup, because it would need to dynamically figure out whether we're running with TSan or not, plus we'd need to add an indirection to each access (to read the value of the tag). I'd really prefer to keep the value as a well-defined constant in TSan.

Tue, Apr 25, 5:23 AM · Restricted Project
dvyukov added inline comments to D32382: [tsan] Track external tags in thread traces.
Tue, Apr 25, 5:21 AM · Restricted Project

Apr 23 2017

dvyukov added reviewers for D32408: [ASAN] Add interceptor for __longjmp_chk: alekseyshl, vitalybuka.
Apr 23 2017, 11:11 PM
dvyukov accepted D32402: Add missing acquire_load to call_once overload..
Apr 23 2017, 10:06 AM

Apr 22 2017

dvyukov accepted D32384: [tsan] Include __tsan_external_* API from a header file instead of declaring them manually.
Apr 22 2017, 2:09 AM · Restricted Project
dvyukov accepted D32383: [tsan] Remove the extra word "object" from description of external races.
Apr 22 2017, 1:59 AM · Restricted Project

Apr 21 2017

dvyukov accepted D32365: [sanitizer] Cache SizeClassForTransferBatch in the 32-bit local cache.
Apr 21 2017, 12:12 PM
dvyukov accepted D32360: [tsan] Refactor __tsan_external_read/__tsan_external_write to avoid code duplication.
Apr 21 2017, 10:41 AM · Restricted Project
dvyukov accepted D32359: [tsan] Track external API accesses as 1-byte accesses (instead of 8-byte).
Apr 21 2017, 10:30 AM · Restricted Project
dvyukov added a comment to D32310: [scudo] Bypass Quarantine if its size is set to 0.

which will be checked in due time.

Apr 21 2017, 10:27 AM
dvyukov accepted D32358: [tsan] Publish the TSan external API in tsan_interface.h.
Apr 21 2017, 10:24 AM · Restricted Project
dvyukov added a comment to D31630: [tsan] Detect races on modifying accesses in Swift code.

Hi Kuba,

I've seen a bunch of changes from you and they all are marked in my inbox. The past 1.5 weeks I was travelling and next week I am OOO so won't be able to review them. Just wanted to let you know.

I am back. Slowly working on backlog.

Apr 21 2017, 10:17 AM · Restricted Project
dvyukov added inline comments to D31689: [tsan] Summary should point to "responsible caller" for external races.
Apr 21 2017, 7:11 AM · Restricted Project
dvyukov added a comment to D31630: [tsan] Detect races on modifying accesses in Swift code.

We have 3 potential users for the external API (Go, Java, races on fd, potentially more in future).

Apr 21 2017, 6:48 AM · Restricted Project
dvyukov added a comment to D31630: [tsan] Detect races on modifying accesses in Swift code.

I don't like that we sprinkle swift-specific bits throughout the code when the external API was meant to be general enough to cover all such cases.
We have the special tag for swift, so it really seems to me that it should be the only swift-specific bit here and the rest must be handled by the external API on general basis. We have 3 potential users for the external API (Go, Java, races on fd, potentially more in future). So I would be really interested in making the external API general and flexible enough to support all of them, rather than later sprinkle Go/Java/fd/etc-specific bits throughout the code again later.

Apr 21 2017, 6:42 AM · Restricted Project
dvyukov accepted D31553: [tsan] Ignore memory accesses for libignored modules for "external" races.
Apr 21 2017, 6:05 AM · Restricted Project
dvyukov added inline comments to D31684: [sanitizer] Fix various issues reported by Clang Static Analyzer [NFC].
Apr 21 2017, 5:21 AM · Restricted Project
dvyukov accepted D31734: [tsan] Add a test for "external" API that checks the dup suppression is based on the caller PC.
Apr 21 2017, 4:45 AM · Restricted Project
dvyukov accepted D31449: [tsan] Don't report bugs from interceptors called from libignored modules.
Apr 21 2017, 4:45 AM · Restricted Project
dvyukov added a comment to D31729: [tsan] Mark "responsible frames" in stack traces to show which frame contains the race.

I am not completely follow motivation for this. Is it meant for user? Or for any automated tools?
For automated tools we already have SUMMARY line. User must be proficient enough to understand what happens. And in the end this is not specific to libc, and the guilty frame is not necessary the one just above libc. Consider a race in std::vector, it's probably not std::vector code that is guilty. And this extends just to any library, consider you have race in libfoo, but it's actually your code that misuses libfoo. We don't have enough info to provide precise signal. What we provide here is a weak, potentially incorrect signal.

Apr 21 2017, 4:33 AM · Restricted Project
dvyukov accepted D32310: [scudo] Bypass Quarantine if its size is set to 0.

If we actually plan to use such configuration, does it make sense to check header for corruption when we reallocate a block (in allocate)? That will give us at least some windows for UAF detection.

Apr 21 2017, 1:46 AM

Apr 20 2017

dvyukov accepted D32299: [scudo] Remove GetActuallyAllocatedSize calls from the fast path.
Apr 20 2017, 10:35 AM
dvyukov accepted D32242: [scudo] Minor changes and refactoring.

LGTM with a nit

Apr 20 2017, 6:16 AM

Apr 19 2017

dvyukov added a comment to D31630: [tsan] Detect races on modifying accesses in Swift code.

Hi Kuba,

I've seen a bunch of changes from you and they all are marked in my inbox. The past 1.5 weeks I was travelling and next week I am OOO so won't be able to review them. Just wanted to let you know.

Apr 19 2017, 1:03 PM · Restricted Project
dvyukov added a comment to D31947: [scudo] Android support groundwork.

@dvyukov would it be acceptable to get this patch out in its current form and use this as a base for the further improvement you suggested?
Namely: improve contention, potential use of the tsan TLS slot, rework thread/global initialization.

Apr 19 2017, 11:32 AM

Apr 18 2017

dvyukov added a comment to D31947: [scudo] Android support groundwork.

First of all, do you have any benchmarks? Single-threaded, multi-threaded with/without contention. How do profiles look like?

I have shared with Aleksey some Flame profiles, I can send that to you as well. This ended up with the couple of optimizations he recently did.

Apr 18 2017, 8:44 AM
dvyukov added inline comments to D30583: [Asan, Tsan] Generalize means the sanitizers work with memory.
Apr 18 2017, 5:35 AM · Restricted Project
dvyukov added a comment to D31395: [Asan] Disable inline instrumentation for MMU-less targets.

Ivan, do you have commit access? Or I need to land it?

Apr 18 2017, 5:04 AM · Restricted Project
dvyukov accepted D31395: [Asan] Disable inline instrumentation for MMU-less targets.

I was on vacation/ooo, sorry for delays.

Apr 18 2017, 5:03 AM · Restricted Project
dvyukov added a comment to D31947: [scudo] Android support groundwork.

First of all, do you have any benchmarks? Single-threaded, multi-threaded with/without contention. How do profiles look like?

Apr 18 2017, 4:37 AM
dvyukov added a comment to D31947: [scudo] Android support groundwork.

Android doesn't support thread_local

Apr 18 2017, 2:34 AM

Apr 7 2017

dvyukov added a comment to D31630: [tsan] Detect races on modifying accesses in Swift code.

Hi Kuba,

Apr 7 2017, 1:54 PM · Restricted Project

Apr 2 2017

dvyukov added a comment to D31449: [tsan] Don't report bugs from interceptors called from libignored modules.
  1. s/ignore_reads_and_writes/ignore_reads_writes_and_reports/ does not look like a good idea to me, because these things are not necessary related. If we go this route we need separate flags.
  2. From the description it seems that your intention is to ignore all reports, but you are ignoring only deadlocks. There are many more types of reports.
Apr 2 2017, 3:08 AM · Restricted Project
dvyukov added inline comments to D31449: [tsan] Don't report bugs from interceptors called from libignored modules.
Apr 2 2017, 3:03 AM · Restricted Project
dvyukov added a comment to D31553: [tsan] Ignore memory accesses for libignored modules for "external" races.

Wait, the external API was meant specifically to be used from non-instrumented libraries. Quoting you in D28836:

It might not be feasible/easy to recompile the library with TSan instrumentation... The idea of this patch is to allow a non-instrumented library to call into TSan runtime.

With this change it all become pointless. We annotate non-instrumented libraries and then ignore that. What am I missing?

Apr 2 2017, 1:57 AM · Restricted Project

Mar 30 2017

dvyukov added a comment to D31449: [tsan] Don't report bugs from interceptors called from libignored modules.

When an interceptor comes from a non-instrumented library, we set thr->in_ignored_lib=true. This causes SCOPED_TSAN_INTERCEPTOR to call the real function an skip all tsan processing. Consequently mutex lock/unlock operations in non-instrumented libraries are not handled by tsan already. So it's not clear to me how you get deadlock reports there. What am I missing?

Mar 30 2017, 5:49 AM · Restricted Project
dvyukov accepted D31475: [tsan] Add interceptor for xpc_connection_cancel to avoid false positives.
Mar 30 2017, 5:24 AM · Restricted Project

Mar 28 2017

dvyukov added a comment to D31354: [tsan] Assert to make sure we don't try to Acquire() or Release() a NULL pointer.

I see that we already exclude the first page from app memory on x86_64:

static const uptr kLoAppMemBeg   = 0x000000001000ull;

So I think a better check would be:

CHECK(IsAppMem(addr));

It will also check for any other bogus addresses, like random values, NULL+epsilon (&null_ptr->field) and also will not duplicate mapping logic.

Mar 28 2017, 1:11 AM

Mar 27 2017

dvyukov accepted D31376: [sanitizers] Avoid using -fomit-frame-pointer on Darwin.
Mar 27 2017, 6:56 AM
dvyukov added a comment to D31395: [Asan] Disable inline instrumentation for MMU-less targets.

You can use -asan-instrumentation-with-call-threshold=0 for this without any changes to llvm.

Mar 27 2017, 6:40 AM · Restricted Project

Mar 26 2017

dvyukov committed rL298809: tsan: add new mutex annotations.
tsan: add new mutex annotations
Mar 26 2017, 8:43 AM
dvyukov closed D31093: tsan: add new mutex annotations.

Submitted in 298809.

Mar 26 2017, 8:40 AM
dvyukov added inline comments to D31093: tsan: add new mutex annotations.
Mar 26 2017, 8:38 AM
dvyukov updated the diff for D31093: tsan: add new mutex annotations.
Mar 26 2017, 8:37 AM
dvyukov accepted D31355: [tsan] Only Acquire/Release GCD queues if they're not NULL.
Mar 26 2017, 2:09 AM
dvyukov added a comment to D31354: [tsan] Assert to make sure we don't try to Acquire() or Release() a NULL pointer.

What was the bug? How did it manifest?
I somewhat afraid of breaking some existing code. Currently we consider memory around 0 to be "user memory". And in fact it's possible to mmap the first page at least on some linuxes, not sure about other OSes. And there is some effort to port sanitizers to mmu-less environment (https://reviews.llvm.org/D30583). Another possible use if you have N virtual entities and use N as address passed to acquire/release annotations (not perfect, but currently valid).
If we are excluding NULL from user memory, then I think we need to change IsAppMem to return false for NULL. That will make behavior consistent across all functions. Acquire/Release already check IsAppMem for the passed address (at least in debug build). It will also make simpler to undo this decision in some particular contexts.

Mar 26 2017, 2:05 AM

Mar 24 2017

dvyukov added a comment to D31093: tsan: add new mutex annotations.

PTAL

Mar 24 2017, 4:10 AM
dvyukov updated the diff for D31093: tsan: add new mutex annotations.
Mar 24 2017, 4:09 AM
dvyukov updated the diff for D31093: tsan: add new mutex annotations.
Mar 24 2017, 4:07 AM

Mar 23 2017

dvyukov added inline comments to D31093: tsan: add new mutex annotations.
Mar 23 2017, 1:57 AM

Mar 22 2017

dvyukov committed rL298492: tsan: fix a typo.
tsan: fix a typo
Mar 22 2017, 2:43 AM
dvyukov updated the diff for D31093: tsan: add new mutex annotations.
Mar 22 2017, 2:41 AM
dvyukov added a comment to D31093: tsan: add new mutex annotations.

Tests now have full coverage of annotations.

Mar 22 2017, 2:41 AM
dvyukov updated the diff for D31093: tsan: add new mutex annotations.

added more tests

Mar 22 2017, 2:39 AM

Mar 21 2017

dvyukov added a comment to D31093: tsan: add new mutex annotations.

Sounds like a great improvement, especially the introduction of a public tsan_interface.h header file.

I didn't test the patch yet, but do I understand correctly that this now detects actual deadlocks and reports them via ReportDeadlock? Should we change the message in that case from "potential deadlock" to "deadlock detected"? Can we add a test for it? (Doesn't need to be part of this patch, though.)

Mar 21 2017, 10:56 AM
dvyukov added inline comments to D31093: tsan: add new mutex annotations.
Mar 21 2017, 10:46 AM
dvyukov updated the diff for D31093: tsan: add new mutex annotations.

addressed review comments

Mar 21 2017, 10:46 AM
dvyukov committed rL298383: tsan: fix pie_no_aslr test.
tsan: fix pie_no_aslr test
Mar 21 2017, 8:50 AM
dvyukov committed rL298378: tsan: support __ATOMIC_HLE_ACQUIRE/RELEASE flags.
tsan: support __ATOMIC_HLE_ACQUIRE/RELEASE flags
Mar 21 2017, 7:41 AM
dvyukov committed rL298372: tsan: add test for pie/no aslr.
tsan: add test for pie/no aslr
Mar 21 2017, 6:56 AM

Mar 17 2017

dvyukov added a comment to D31093: tsan: add new mutex annotations.

I still need to look at this with fresh head next week, but it is ready for first review pass.
Need to add more tests. It's not that I did not test, I've worked out interface and tested on private programs.

Mar 17 2017, 12:16 PM
dvyukov created D31093: tsan: add new mutex annotations.
Mar 17 2017, 12:14 PM

Mar 13 2017

dvyukov added a comment to D30583: [Asan, Tsan] Generalize means the sanitizers work with memory.

Few suggestions if you want to upstream this:

  • remove unchanged files, unnecessary ifdefs and todo's
  • start with just asan (tsan is more complex)
  • use the existing asan compiler instrumentation that inserts function calls, and do the rest in runtime (at least in the first version, this will greatly simplify the change)
Mar 13 2017, 11:49 AM · Restricted Project

Mar 8 2017

dvyukov added inline comments to D30583: [Asan, Tsan] Generalize means the sanitizers work with memory.
Mar 8 2017, 5:02 AM · Restricted Project

Feb 16 2017

dvyukov accepted D30023: [tsan] Provide external tags (object types) via debugging API.
Feb 16 2017, 1:11 AM · Restricted Project

Feb 9 2017

dvyukov accepted D29728: Remove strict tid checks from the mac implementation of BlockingMutex.

LGTM if the comment is moved

Feb 9 2017, 10:36 AM