| From: | Jacob Champion <pchampion(at)vmware(dot)com> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Andres Freund <andres(at)anarazel(dot)de>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Subject: | Re: Support for NSS as a libpq TLS backend |
| Date: | 2020-11-11 18:17:03 |
| Message-ID: | 5C27CF6F-5BD3-4639-AAA6-73465595B6DF@vmware.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Nov 10, 2020, at 2:28 PM, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>
> Digging through the archives from when this landed in curl, the assertion
> failure was never fully identified back then but happened spuriously. Which
> version of NSPR is this happening with?
This is NSPR 4.29, with debugging enabled. The fd that causes the
assertion is the custom layer that's added during be_tls_open_server(),
which connects a Port as the layer secret. It looks like NSPR is trying
to help surface potential memory leaks by asserting if the secret is
non-NULL at the time the stack is being closed.
In this case, it doesn't matter since the Port lifetime is managed
elsewhere, but it looks easy enough to add a custom close in the way
that cURL and the NSPR test programs [1] do. Sample patch attached,
which gets me to the end of the tests without any assertions. (Two
failures left on my machine.)
--Jacob
[1] https://hg.mozilla.org/projects/nspr/file/bf6620c143/pr/tests/nblayer.c#l354
| Attachment | Content-Type | Size |
|---|---|---|
| patch | application/octet-stream | 1.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2020-11-11 18:28:06 | Re: Allow some recovery parameters to be changed with reload |
| Previous Message | Soumyadeep Chakraborty | 2020-11-11 17:53:48 | Re: PATCH: Attempt to make dbsize a bit more consistent |