Spurious TSan reports

[karwa]

Describe the bug

I'm seeing TSan reports of access races which don't make sense. They seem to only pop when calling this code in parallel, even though it has no global state (so concurrent invocations should not be touching any shared mutable data anyway).

I get a message that the calling function is a global variable (?!) that is mutated by multiple threads. A user of my package gets a message that 'type metadata instantiation cache for Swift.Optional is a global variable'. It seems to vary quite a bit. More details in the issue:

karwa/swift-url#166

On the console, I see:

==================
WARNING: ThreadSanitizer: Swift access race (pid=41452)
  Modifying access of Swift variable at 0x000100ffe33a by thread T1:
    #0 closure #3 in _urlFromBytes_impl<A, B>(_:baseURL:callback:) Parser.swift:74 (spm-tsancheck:x86_64+0x100102a60)
    #1 partial apply for closure #3 in _urlFromBytes_impl<A, B>(_:baseURL:callback:) <compiler-generated> (spm-tsancheck:x86_64+0x100102deb)
    #2 Either.map<A, B>(left:right:) Either.swift:32 (spm-tsancheck:x86_64+0x1001e4b72)
    #3 _urlFromBytes_impl<A, B>(_:baseURL:callback:) Parser.swift:69 (spm-tsancheck:x86_64+0x10010107c)
    #4 closure #1 in urlFromBytes<A>(_:baseURL:) Parser.swift:50 (spm-tsancheck:x86_64+0x100100624)
    #5 partial apply for closure #1 in urlFromBytes<A>(_:baseURL:) <compiler-generated> (spm-tsancheck:x86_64+0x10010068d)
    #6 thunk for @callee_guaranteed (@unowned UnsafeBufferPointer<UInt8>) -> (@owned WebURL?, @error @owned Error) <compiler-generated> (spm-tsancheck:x86_64+0x1001011cb)
    #7 partial apply for thunk for @callee_guaranteed (@unowned UnsafeBufferPointer<UInt8>) -> (@owned WebURL?, @error @owned Error) <compiler-generated> (spm-tsancheck:x86_64+0x10010129f)
    #8 UnsafeBufferPointer.withContiguousStorageIfAvailable<A>(_:) <null>:2 (libswiftCore.dylib:x86_64+0x25296e)
    #9 WebURL.init<A>(utf8:) WebURL.swift:92 (spm-tsancheck:x86_64+0x100270a34)
    #10 closure #1 in WebURL.init<A>(_:) WebURL.swift:54 (spm-tsancheck:x86_64+0x100270995)
    #11 thunk for @callee_guaranteed (@unowned UnsafeBufferPointer<UInt8>) -> (@owned WebURL?, @error @owned Error) <compiler-generated> (spm-tsancheck:x86_64+0x1001011cb)
    #12 partial apply for thunk for @callee_guaranteed (@unowned UnsafeBufferPointer<UInt8>) -> (@owned WebURL?, @error @owned Error) <compiler-generated> (spm-tsancheck:x86_64+0x100270b6f)
    #13 String.UTF8View.withContiguousStorageIfAvailable<A>(_:) <null>:2 (libswiftCore.dylib:x86_64+0x1ba109)
    #14 WebURL.init<A>(_:) WebURL.swift:54 (spm-tsancheck:x86_64+0x1002707e6)
    #15 closure #1 in doIt() main.swift:6 (spm-tsancheck:x86_64+0x100277dd8)
    #16 partial apply for thunk for @callee_guaranteed (@unowned Int) -> () <null>:2 (libswiftDispatch.dylib:x86_64+0x5f90)
    #17 _dispatch_client_callout2 <null>:2 (libdispatch.dylib:x86_64+0x3349)

  Previous modifying access of Swift variable at 0x000100ffe33a by main thread:
    #0 closure #3 in _urlFromBytes_impl<A, B>(_:baseURL:callback:) Parser.swift:74 (spm-tsancheck:x86_64+0x100102a60)
    #1 partial apply for closure #3 in _urlFromBytes_impl<A, B>(_:baseURL:callback:) <compiler-generated> (spm-tsancheck:x86_64+0x100102deb)
    #2 Either.map<A, B>(left:right:) Either.swift:32 (spm-tsancheck:x86_64+0x1001e4b72)
    #3 _urlFromBytes_impl<A, B>(_:baseURL:callback:) Parser.swift:69 (spm-tsancheck:x86_64+0x10010107c)
    #4 closure #1 in urlFromBytes<A>(_:baseURL:) Parser.swift:50 (spm-tsancheck:x86_64+0x100100624)
    #5 partial apply for closure #1 in urlFromBytes<A>(_:baseURL:) <compiler-generated> (spm-tsancheck:x86_64+0x10010068d)
    #6 thunk for @callee_guaranteed (@unowned UnsafeBufferPointer<UInt8>) -> (@owned WebURL?, @error @owned Error) <compiler-generated> (spm-tsancheck:x86_64+0x1001011cb)
    #7 partial apply for thunk for @callee_guaranteed (@unowned UnsafeBufferPointer<UInt8>) -> (@owned WebURL?, @error @owned Error) <compiler-generated> (spm-tsancheck:x86_64+0x10010129f)
    #8 UnsafeBufferPointer.withContiguousStorageIfAvailable<A>(_:) <null>:2 (libswiftCore.dylib:x86_64+0x25296e)
    #9 WebURL.init<A>(utf8:) WebURL.swift:92 (spm-tsancheck:x86_64+0x100270a34)
    #10 closure #1 in WebURL.init<A>(_:) WebURL.swift:54 (spm-tsancheck:x86_64+0x100270995)
    #11 thunk for @callee_guaranteed (@unowned UnsafeBufferPointer<UInt8>) -> (@owned WebURL?, @error @owned Error) <compiler-generated> (spm-tsancheck:x86_64+0x1001011cb)
    #12 partial apply for thunk for @callee_guaranteed (@unowned UnsafeBufferPointer<UInt8>) -> (@owned WebURL?, @error @owned Error) <compiler-generated> (spm-tsancheck:x86_64+0x100270b6f)
    #13 String.UTF8View.withContiguousStorageIfAvailable<A>(_:) <null>:2 (libswiftCore.dylib:x86_64+0x1ba109)
    #14 WebURL.init<A>(_:) WebURL.swift:54 (spm-tsancheck:x86_64+0x1002707e6)
    #15 closure #1 in doIt() main.swift:6 (spm-tsancheck:x86_64+0x100277dd8)
    #16 partial apply for thunk for @callee_guaranteed (@unowned Int) -> () <null>:2 (libswiftDispatch.dylib:x86_64+0x5f90)
    #17 _dispatch_client_callout2 <null>:2 (libdispatch.dylib:x86_64+0x3349)
    #18 _swift_dispatch_apply_current <null>:2 (libswiftDispatch.dylib:x86_64+0x6051)
    #19 main main.swift:10 (spm-tsancheck:x86_64+0x100277af5)

  Location is global 'urlFromBytes<A>(_:baseURL:)' at 0x000000000000 (spm-tsancheck+0x00010010033a)

  Thread T1 (tid=1001327, running) is a GCD worker thread

SUMMARY: ThreadSanitizer: Swift access race Parser.swift:74 in closure #3 in _urlFromBytes_impl<A, B>(_:baseURL:callback:)
==================

Lots of details about this are suspicious. Particularly the 'location' at address 0.

Steps To Reproduce
Steps to reproduce the behavior:

1. Clone the following repo: https://github.com/karwa/swift-tsan-bug
2. Run with swift run --sanitize=thread
3. If that fails to produce a TSan report, try swift test --sanitize=thread

Expected behavior

There is no shared mutable state here (at least, not from my code; the Swift runtime may have shared mutable state). TSan should not report any data races. Whether this is a bug in TSan, or in the Swift runtime, I don't know; but I'm quite sure there isn't an actual data race here.

Screenshots

There are some screenshots in the linked bug report: karwa/swift-url#166

Environment (please fill out the following information)

• OS: macOS 12.5.1
• Xcode Version/Tag/Branch: 13.4.1, 14RC, also reproduced using a recent 5.7 nightly

[karwa]

I'm 100% sure there is no data race in the library code, but let me know if I can help explain any of it.

I do try to narrow down these bug reports as much as possible, but in this case there isn't really much I can say other than: I promise there is no actual race in the library code, and the reports TSan generates don't make any sense even if there were a race.

[karwa]

Possible dupe of #56405

When I try the code in that linked bug report verbatim, I don't get any TSan reports. However, if I change it to run in the context of a Dispatch.concurrentPerform, I do:

import Dispatch

DispatchQueue.concurrentPerform(iterations: 10_000) { _ in
    var g = MYRNG()
    _  = callReturnNext([0], using: &g)
}

This seems to be the same sort of thing as is happening in my case - an empty struct, passed inout to a generic function. Here we get a spurious race report, in other instances we get a crash within TSan itself (see also: #61244).

ThreadSanitizer:DEADLYSIGNAL
==34290==ERROR: ThreadSanitizer: SEGV on unknown address 0x000000000000 (pc 0x00010cd60687 bp 0x7ff7b51eef90 sp 0x7ff7b51eef50 T6415223)
==34290==The signal is caused by a READ memory access.
==34290==Hint: address points to the zero page.
ThreadSanitizer:DEADLYSIGNAL
==34290==Launching Symbolizer process: /usr/bin/atos -p 34290 
ThreadSanitizer:DEADLYSIGNAL
ThreadSanitizer:DEADLYSIGNAL
    #0 __tsan::MemoryAccess(__tsan::ThreadState*, unsigned long, unsigned long, int, bool, bool) <null>:2 (libclang_rt.tsan_osx_dynamic.dylib:x86_64+0x60687)
    #1 __tsan::ExternalAccess(void*, unsigned long, void*, unsigned long) <null>:2 (libclang_rt.tsan_osx_dynamic.dylib:x86_64+0x2adbd)
    #2 callReturnNext<A>(_:using:) <null>:2 (a.out:x86_64+0x100003ade)
    #3 closure #1 in  <null>:2 (a.out:x86_64+0x100003bb0)
    #4 partial apply for thunk for @callee_guaranteed (@unowned Int) -> () <null>:2 (libswiftDispatch.dylib:x86_64+0x5f90)
    #5 thunk for @escaping @callee_guaranteed (@unowned Int) -> () <null>:2 (libswiftDispatch.dylib:x86_64+0x5fb3)
    #6 __wrap_dispatch_apply_block_invoke <null>:2 (libclang_rt.tsan_osx_dynamic.dylib:x86_64+0x815c9)
    #7 _dispatch_client_callout2 <null>:2 (libdispatch.dylib:x86_64+0x3349)
    #8 _dispatch_apply_invoke_and_wait <null>:2 (libdispatch.dylib:x86_64+0x15c44)
    #9 _dispatch_apply_with_attr_f <null>:2 (libdispatch.dylib:x86_64+0x15160)
    #10 dispatch_apply <null>:2 (libdispatch.dylib:x86_64+0x15326)
    #11 wrap_dispatch_apply <null>:2 (libclang_rt.tsan_osx_dynamic.dylib:x86_64+0x81531)
    #12 _swift_dispatch_apply_current <null>:2 (libswiftDispatch.dylib:x86_64+0x6051)
    #13 static OS_dispatch_queue.concurrentPerform(iterations:execute:) <null>:2 (libswiftDispatch.dylib:x86_64+0x5f0b)
    #14 main <null>:2 (a.out:x86_64+0x100003897)
    #15 start <null>:2 (dyld:x86_64+0x552d)

==34290==Register values:
rax = 0x000080000000574e  rbx = 0x0000000000000000  rcx = 0x000000000000574e  rdx = 0x0000000000000000  
rdi = 0x0000800000000000  rsi = 0x0001000000000000  rbp = 0x00007ff7b51eef90  rsp = 0x00007ff7b51eef50  
 r8 = 0x0000000000000001   r9 = 0x0000000000000000  r10 = 0x000000010ad18001  r11 = 0x0004000000000000  
r12 = 0x00000c000000574e  r13 = 0x000000010ad13adf  r14 = 0x0000000000000000  r15 = 0x0000000000000000  
ThreadSanitizer can not provide additional info.
SUMMARY: ThreadSanitizer: SEGV (libclang_rt.tsan_osx_dynamic.dylib:x86_64+0x60687) in __tsan::MemoryAccess(__tsan::ThreadState*, unsigned long, unsigned long, int, bool, bool)+0x97
==34290==ABORTING
zsh: abort      TSAN_OPTIONS="verbosity=3" ./a.out

[weissi]

@karwa do you think we can close this as dupe of #56405 ?

[karwa]

@weissi Probably, yes. I only discovered that report after I filed this one. That said, the code in the original report doesn't show an issue any more:

When I try the code in that linked bug report verbatim, I don't get any TSan reports. However, if I change it to run in the context of a Dispatch.concurrentPerform, I do

[AnthonyLatsis]

@weissi Could it help to at least transfer these TSan issues to our LLVM fork (you cannot easily transfer across orgs unfortunately)? I don’t see much to gain from tracking them here. We’ll just close them eventually without getting the right eyes on them at this rate.

[weissi]

@AnthonyLatsis do you mean this?

[AnthonyLatsis]

Yes.

[AnthonyLatsis]

Could it help to at least transfer these TSan issues to our LLVM fork (you cannot easily transfer across orgs unfortunately)? I don’t see much to gain from tracking them here. We’ll just close them eventually without getting the right eyes on them at this rate.

cc @hborla