On OS X, __thread variables are lazily heap-allocated (with malloc). Therefore, they're recognized as heap blocks (which is what they are) and not as TLS variables in TSan reports. Figuring out if a heap block is a TLS or not is difficult (in malloc interceptor we could analyze the caller and then mark the object), so let's instead modify the tests so that we expect the report to say "Location is heap block" instead of "Location is TLS".
Details
Diff Detail
Event Timeline
test/tsan/tls_race.cc | ||
---|---|---|
23 | The stack looks like this: * frame #0: 0x0000000100077890 libclang_rt.tsan_osx_dynamic.dylib`::wrap_malloc(size=4294971592) at sanitizer_malloc_mac.inc:96 frame #1: 0x00007fff86555d7d libdyld.dylib`tlv_allocate_and_initialize_for_key + 370 frame #2: 0x00007fff8655652c libdyld.dylib`tlv_get_addr + 296 frame #3: 0x0000000100000dc7 tls_race.cc.tmp`main + 55 at tls_race.cc:14 [opt] frame #4: 0x00007fff865565ad libdyld.dylib`start + 1 To figure out this is a TLS, we could recognize that the caller is tlv_allocate_and_initialize_for_key, but for that we'd need to symbolicate first. FYI, there are no other calls to malloc from tlv_allocate_and_initialize_for_key. This function is internal (non-interceptible). If you have any easy solution in mind, please tell me. |
test/tsan/tls_race.cc | ||
---|---|---|
23 | OK, let's leave it as is for now. |
How does the heap block allocation stack look like? Is it possible to figure out that this is TLS from the stack?