Re: Valgrind failures in Apply Launcher's bgworker_quickdie() exit

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Valgrind failures in Apply Launcher's bgworker_quickdie() exit
Дата
Msg-id 20181216214800.rja7p4jtqt255lc4@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Valgrind failures in Apply Launcher's bgworker_quickdie() exit  (Thomas Munro <thomas.munro@enterprisedb.com>)
Ответы Re: Valgrind failures in Apply Launcher's bgworker_quickdie() exit  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Hi,

On 2018-12-17 08:25:38 +1100, Thomas Munro wrote:
> On Mon, Dec 17, 2018 at 7:57 AM Andres Freund <andres@anarazel.de> wrote:
> > The interesting bit is that if I replace the _exit(2) in
> > bgworker_quickdie() with an exit(2) (i.e. processing atexit handlers),
> > or manully add an OPENSSL_cleanup() before the _exit(2), valgrind
> > doesn't find errors.
> 
> Weird.  Well I can see that there were bugs last year where OpenSSL
> failed to clean up its thread locals[1], and after they fixed that,
> cases where it bogusly cleaned up someone else's thread locals[2].
> Maybe there is some interference between pthread keys or something
> like that.
> 
> [1] https://github.com/openssl/openssl/issues/3033
> [2] https://github.com/openssl/openssl/issues/3584

What confuses the heck out of me is that it happens on _exit(). Those
issues ought to be only visible when doing exit(), no?

I guess there's also a good argument to make that valgrind running it's
intercept in the _exit() case is a bit dubious (given that's going to be
used in cases where e.g. a signal handler might have interrupted a
malloc), but given the stacktraces here I don't think that can be the
cause.

Greetings,

Andres Freund


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

Предыдущее
От: Erik Rijkers
Дата:
Сообщение: Re: select limit error in file_fdw
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: gist microvacuum doesn't appear to care about hot standby?