Re: [PATCH BZ#20422] Do not allow asan/msan/tsan and fortify at the same time.

[Florian Weimer <fweimer at redhat dot com>]

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
> verification runs.

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.

#include <pthread.h>
#include <stdbool.h>
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include <unistd.h>

__attribute__ ((noinline, noclone))
static void
check_value (const char *s, int expected)
{
  int actual;
  if (sscanf (s, "Unknown error %d", &actual) != 1)
    {
      printf ("error: scanf parsing failed: [[%s]]\n", s);
      _exit (1);
    }
  if (actual != expected)
    {
      printf ("error: scanf returned wrong value\n");
      printf ("error:  expected: %d\n", expected);
      printf ("error:  actual:   %d\n", actual);
      _exit (1);
    }
}

static void *
thread_func (void *closure)
{
  int *pval = closure;
  while (true)
    {
      check_value (strerror (*pval), *pval);
    }
  return NULL;
}

int
main ()
{
  int val1000 = 1000;
  pthread_t thr;
  if (pthread_create (&thr, NULL, thread_func, &val1000) != 0)
    abort ();
  int val9999 = 9999;
  thread_func (&val9999);
}


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.

Florian