Created attachment 1914471 [details]
sem_timedwait.tar

In the sample reproducer it is expected to have the output:

thread_func_one loop 1
thread_func_two loop 1
thread_func_one loop 2
thread_func_two loop 2
thread_func_one loop 3
thread_func_two loop 3
thread_func_one loop 4
thread_func_two loop 4
thread_func_one loop 5
thread_func_two loop 5
thread_func_one loop 6
thread_func_two loop 6
thread_func_one loop 7
thread_func_two loop 7
thread_func_one loop 8
thread_func_two loop 8
thread_func_one loop 9
thread_func_one done
thread_func_two loop 9
thread_func_two done
data_one.count=0 data_one.other=0
data_two.count=0 data_two.other=0

Instead, it hangs.

The problem is that libasan is binding to the wrong sem_init symbol.
It is binding to __old_sem_init instead of __new_sem_init.

The issue should be due to libasan not choosing the symbol from
libpthread.

A workaround is to play with the way __new_sem_init works, for example.
use the pseudo patch:

-sem_init(&sem_one, 0,1);
+sem_init(&sem_one, 0,2);

  This is due to glibc code:
...
__new_sem_init (sem_t *sem, int pshared, unsigned int value)
...
#if __HAVE_64B_ATOMICS
  isem->data = value;
#else
  isem->value = value << SEM_VALUE_SHIFT;
  /* pad is used as a mutex on pre-v9 sparc and ignored otherwise.  */
  isem->pad = 0;
  isem->nwaiters = 0;
#endif
...

SEM_VALUE_SHIFT is one.