Re: Configure with thread sanitizer fails the thread test

From: Andres Freund <andres(at)anarazel(dot)de>
To: Ewan Higgs <ewan_higgs(at)yahoo(dot)co(dot)uk>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Configure with thread sanitizer fails the thread test
Date: 2015-08-17 17:40:20
Message-ID: 20150817174020.GE10786@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-08-17 17:41:06 Re: More WITH
Previous Message David Fetter 2015-08-17 17:37:52 Re: More WITH