versioned pthread_cond interceptors

[GoogleCodeExporter]

Glibc provides 2 versions of pthread_cond functions -- 3.3.2 and 2.2.5. 
sizeof(pthread_cond_t) is different in these versions. So if user call is 
routed into the wrong real function, it corrupts memory or hangs.
While version 2.2.5 is more than 10 years old, so vendors build their libraries 
against it (for example libGL.so from Nvidia drivers).
Currently tsan routes all calls into 3.3.2 real functions. Consequently any 
applications that use libraries built against glibc 2.2.5 hang or corrupt 
memory.
Tsan provides legacy_pthread_cond flag that can be used to alter pthread_cond 
interceptors behavior. If legacy_pthread_cond=true, then both versions will 
work, but PSHARED conds will break (and maybe something else that we don't know 
about).

We've investigated the possibility of properly exporting 2 versions of each 
interceptor. But as turned out versioned symbols are not supported in 
executable (only in dynamic libraries). GNU ld kind of supports it ATM, but 
it's undocumented behavior. Gold does not support it at all.

The current plan is:
- remove pthread_cond interceptors from asan/msan to relieve them from this 
pain.
- continue to rely on legacy_pthread_cond flag in tsan (it seems to fix 
chromium and webrtc)

Original issue reported on code.google.com by dvyu...@google.com on 14 Apr 2014 at 9:30

[GoogleCodeExporter]

Alexey, why pthread_cond interceptors were moved to sanitizer_common? I've 
found commit 192774, but there is no explanation. Can we remove them?
The only consequence that I see is false negatives in rare cases of 
pthread_cond misuse. Do I miss something else?

Original comment by dvyu...@google.com on 14 Apr 2014 at 9:32

[GoogleCodeExporter]

FTR, I think it would be possible to inspect the calling DSO (identified with 
the stack trace, walk ELF headers starting with dl_iterate_phdr or similar 
interface) to find out the symbol version it expects.

I'm not sure we want to go there yet.

Original comment by euge...@google.com on 14 Apr 2014 at 9:50

[GoogleCodeExporter]

Yes, too bad I omitted the explanation. I needed to make pthread_cond_* 
interceptors available in sanitizer_common because of the internal (built-in 
in-process) symbolizer. It calls pthread_cond_* functions, and we need to 
redirect these calls to our interceptors to make symbolizer more hermetic.

Original comment by samso...@google.com on 15 Apr 2014 at 11:26

[GoogleCodeExporter]

I've removed pthread_cond_* interceptors from asan/msan in r206423.

Original comment by samso...@google.com on 16 Apr 2014 at 11:38

[GoogleCodeExporter]

How're you going to make the symbolizer "more hermetic" then?

Original comment by gli...@google.com on 17 Apr 2014 at 8:42

[GoogleCodeExporter]

I can redirect pthread_cond_* in symbolizer code to 
__interceptor_pthread_cond_* only if the latter are present in the sanitizer 
runtime.

Original comment by samso...@google.com on 17 Apr 2014 at 6:45

[GoogleCodeExporter]

Alexey, why do we need to redirect pthread_cond_* to 
__interceptor_pthread_cond_*, and why does is not happen automatically in tools 
where we have an interceptor? Do you mean we actually need 
__real_pthread_cond_*?

Dmitry says that TSan includes logic that disables interceptors while we are in 
the symbolizer. Does it solve this issue?

Original comment by euge...@google.com on 18 Apr 2014 at 8:21

[GoogleCodeExporter]

Generally, if we call "pthread_cond_*" from symbolizer code, it will 
automatically be redirected to the interceptor.

However, if the user provides his own pthread_cond_* function, then symbolizer 
will call user function, instead of TSan interceptor or libc version. We know 
that some people actually do it.

Original comment by samso...@google.com on 19 Apr 2014 at 12:00

[GoogleCodeExporter]

pthread_cond interceptors are removed from asan/msan, so they are not affected 
by this issue now.

Tsan routes all pthread_cond interceptors into new glibc 3.3.2 versions. This 
breaks libraries built against glibc 2.2.5.
Tsan provides legacy_pthread_cond flag that fixes old libraries, but breaks 
process-shared cond vars.

It seems to the best we can provide.

Original comment by dvyu...@google.com on 2 Sep 2014 at 2:16

• Changed state: Fixed

[GoogleCodeExporter]

Adding Project:ThreadSanitizer as part of GitHub migration.

Original comment by gli...@google.com on 30 Jul 2015 at 9:21

• Added labels: ProjectThreadSanitizer