Re: Configure with thread sanitizer fails the thread test - Mailing list pgsql-hackers
From | Andres Freund |
---|---|
Subject | Re: Configure with thread sanitizer fails the thread test |
Date | |
Msg-id | 20150817174020.GE10786@awork2.anarazel.de Whole thread Raw |
List | 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 by date: