Closed GoogleCodeExporter closed 9 years ago
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
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
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
I've removed pthread_cond_* interceptors from asan/msan in r206423.
Original comment by samso...@google.com
on 16 Apr 2014 at 11:38
How're you going to make the symbolizer "more hermetic" then?
Original comment by gli...@google.com
on 17 Apr 2014 at 8:42
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
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
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
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
Original issue reported on code.google.com by
dvyu...@google.com
on 14 Apr 2014 at 9:30