From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Valgrind failures in Apply Launcher's bgworker_quickdie() exit |
Date: | 2018-12-16 21:48:00 |
Message-ID: | 20181216214800.rja7p4jtqt255lc4@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2018-12-16 22:03:52 | Re: gist microvacuum doesn't appear to care about hot standby? |
Previous Message | Erik Rijkers | 2018-12-16 21:26:11 | Re: select limit error in file_fdw |