Re: Configure with thread sanitizer fails the thread test

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Configure with thread sanitizer fails the thread test
Дата
Msg-id 20150817174020.GE10786@awork2.anarazel.de
обсуждение исходный текст
Список pgsql-hackers
On 2015-08-17 07:37:45 +0000, Ewan Higgs wrote:
> So I changed volatile to _Atomic and continued (patch is in
> thread_test_atomic.patch). I then ran it against sqlsmith. The good
> news: I didn't happen to find any problems in normal use. The bad
> news: I did find a lot of warnings about improper use of functions
> like malloc and free from signal handlers. I attached the log under
> 'errors.log'.

Aren't pretty much all of those false positives? I checked the first few
and they all look like:

> ==================
> WARNING: ThreadSanitizer: signal-unsafe call inside of a signal (pid=26767)
>     #0 free <null> (libtsan.so.0+0x000000025d09)
>     #1 AllocSetDelete /home/ehiggs/src/download/postgresql/src/backend/utils/mmgr/aset.c:643
(postgres+0x0000009ece3d)
>     #2 MemoryContextDelete /home/ehiggs/src/download/postgresql/src/backend/utils/mmgr/mcxt.c:226
(postgres+0x0000009ef7cc)
>     #3 MemoryContextDeleteChildren /home/ehiggs/src/download/postgresql/src/backend/utils/mmgr/mcxt.c:246
(postgres+0x0000009ef83b)
>     #4 MemoryContextDelete /home/ehiggs/src/download/postgresql/src/backend/utils/mmgr/mcxt.c:209
(postgres+0x0000009ef798)
>     #5 StartChildProcess /home/ehiggs/src/download/postgresql/src/backend/postmaster/postmaster.c:5211
(postgres+0x0000007b2e72)
>     #6 reaper /home/ehiggs/src/download/postgresql/src/backend/postmaster/postmaster.c:2717
(postgres+0x0000007b44ac)
>     #7 <null> <null> (libtsan.so.0+0x0000000236e3)
>     #8 ServerLoop /home/ehiggs/src/download/postgresql/src/backend/postmaster/postmaster.c:1631
(postgres+0x0000007b6f78)
>     #9 PostmasterMain /home/ehiggs/src/download/postgresql/src/backend/postmaster/postmaster.c:1274
(postgres+0x0000007b6f78)
>     #10 main /home/ehiggs/src/download/postgresql/src/backend/main/main.c:223 (postgres+0x0000006f2da9)

This is after a fork. And fork is a async-signal-safe function. So it
seems tsan doesn't properly recognize that we actually "escaped" the
signal handler and are in a new process.

>  #include <stdio.h>
>  #include <stdlib.h>
> +#include <stdatomic.h>
>  #include <unistd.h>
>  #include <netdb.h>
>  #include <sys/types.h>
> @@ -84,11 +85,11 @@ static void func_call_2(void);
>  
>  static pthread_mutex_t init_mutex = PTHREAD_MUTEX_INITIALIZER;
>  
> -static volatile int thread1_done = 0;
> -static volatile int thread2_done = 0;
> +static _Atomic int thread1_done = 0;
> +static _Atomic int thread2_done = 0;
>  
> -static volatile int errno1_set = 0;
> -static volatile int errno2_set = 0;
> +static _Atomic int errno1_set = 0;
> +static _Atomic int errno2_set = 0;
>  
>  #ifndef HAVE_STRERROR_R
>  static char *strerror_p1;

We can't do that because we have to work on older compilers as well. My
suggestion for now would be to disable tsan during configure and only
enable it during the actual build (you can do stuff like make
COPT='-fsanitize...'.

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: More WITH
Следующее
От: Tom Lane
Дата:
Сообщение: Re: More WITH