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

On 9/18/23 20:52, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
>> it seems dikkop is unhappy again, this time because of some OpenSSL
>> stuff. I'm not sure it's our problem - it might be issues with the other
>> packages, or maybe something FreeBSD specific, not sure.
>> ...
>> 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):
> 
> Even weirder, its latest REL_11 run got past that, and instead failed
> in pltcl [1].  I suppose in an hour or two we'll know if v12 also
> changed behavior.
> 

Oh, yeah. Sorry for not mentioning this yesterday ...

I tried removing the openssl-1.1.1v and installed 3.1 instead, which
apparently allowed it to pass the plpython tests. I guess it's due to
some sort of confusion with the openssl-3.0 included in FreeBSD base
(which I didn't realize is there).

> The pltcl test case that is failing is annotated
> 
> -- Test usage of Tcl's "clock" command.  In recent Tcl versions this
> -- command fails without working "unknown" support, so it's a good canary
> -- for initialization problems.
> 
> which is mighty suggestive, but I'm not sure what to look at exactly.
> Perhaps apply "ldd" or local equivalent to those languages' .so files
> and see if they link to the same versions of indirectly-required
> libraries as Postgres is linking to?
> 
> 			regards, tom lane
> 

I have no experience with tcl, but I tried this in the two tclsh
versions installed no the system (8.6 and 8.7):

bsd@freebsd:~ $ tclsh8.7
% clock scan "1/26/2010"
time value too large/small to represent

bsd@freebsd:~ $ tclsh8.6
% clock scan "1/26/2010"
time value too large/small to represent

AFAIK this is what the tcl_date_week(2010,1,26) translates to.

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