This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH BZ#20422] Do not allow asan/msan/tsan and fortify at the same time.
On 09/06/2016 11:20 AM, Yuri Gribov wrote:
But isn't it the same with Valgrind - it doesn't play nice with
sanitizers (because both tools are far too complicated) but noone
really cares to fix this and just people just perform separate
Sure, we can pile workarounds on workarounds, but we get maintenance
problems (like the dlsym error reporting change which broke ASan earlier
this year), and misleading results because the interceptors do not
correctly model the glibc behavior.
For example, the following program has a data race on glibc, but not on
other libcs, and the interceptors appear to assume the other libc's
behavior, and -fsanitize=thread does not report anything.
__attribute__ ((noinline, noclone))
check_value (const char *s, int expected)
if (sscanf (s, "Unknown error %d", &actual) != 1)
printf ("error: scanf parsing failed: [[%s]]\n", s);
if (actual != expected)
printf ("error: scanf returned wrong value\n");
printf ("error: expected: %d\n", expected);
printf ("error: actual: %d\n", actual);
static void *
thread_func (void *closure)
int *pval = closure;
check_value (strerror (*pval), *pval);
int val1000 = 1000;
if (pthread_create (&thr, NULL, thread_func, &val1000) != 0)
int val9999 = 9999;
This also applies to the NSS functions (such as getpwuid) and the locale
handling. All these data races are currently obscured by the
interceptors, I think. We can fix the strerror and getpwuid races with
more TLS data, but for locale, it's not really an option.