Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)

On 9/19/23 04:25, Thomas Munro wrote:
> On Tue, Sep 19, 2023 at 2:04 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>> On Mon, Sep 18, 2023 at 03:11:27PM +0200, Tomas Vondra wrote:
>>> Both 11 and 12 failed with a weird openssl segfaults in plpython tests,
>>> see [2] and [3]. And 13 is stuck in some openssl stuff in plpython
>>> tests, with 100% CPU usage (for ~30h now):
>>>
>>> #0 0x00000000850e86c0 in OPENSSL_sk_insert ()
>>> from /usr/local/lib/libcrypto.so.11
>>> #1 0x00000000850a5848 in CRYPTO_set_ex_data ()
>>> from /usr/local/lib/libcrypto.so.11
>>> ...
>>>
>>> Full backtrace attached. I'm not sure what could possibly be causing
>>> this, except maybe something in FreeBSD? Or maybe there's some confusion
>>> about libraries? No idea.
>>
>> FWIW, I've seen such corrupted and time-sensitive stacks in the past
>> in the plpython tests in builds when python linked to a SSL library
>> different than what's linked with the backend. So that smells like a
>> packaging issue to me.
>
> Could it be confusion due to the presence of OpenSSL 3.0 in the
> FreeBSD base system (/usr/include, /usr/lib) combined with the
> presence of OpenSSL 1.1.1 installed with "pkg install openssl"
> (/usr/local/include, /usr/local/lib)? Tomas, does it help if you "pkg
> remove openssl"?

Oh! That might be it - I didn't realize FreeBSD already has openssl 3.0
already included in the base system, so perhaps installing 1.1.1v leads
to some serious confusion ...

After some off-list discussion with Alvaro I tried removing the 1.1.1v
and installed the openssl31 package, which apparently resolved this (at
which point it ran into the unrelated tcl issue).

Still, this confusion seems rather unexpected, and I'm not sure if
having both 3.0 (from base) and 3.1 (from package) could lead to the
same confusion / crashes. Not sure if it's "our" problem ...

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company