PostgreSQL client crash on connection pools

[andrewhotlab]

Trying to establish a connection pool via TCP/IP with a PGSQL server using a client installed from pkgsrc in a OmniOS r151052 pkgsrc zone, the client crashes and a core dump is generated:

root@jail04:~# /opt/local/bin/pgbench -c 1 -j 1 -h 192.168.0.2 -U synapse synapse                                      
Password: 
pgbench (14.15)
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1
query mode: simple
number of clients: 1
number of threads: 1
number of transactions per client: 10
number of transactions actually processed: 10/10
latency average = 13.081 ms
initial connection time = 45.227 ms
tps = 76.447339 (without initial connection time)

root@jail04:~# /opt/local/bin/pgbench -c 2 -j 2 -h 192.168.0.2 -U synapse synapse
Password: 
pgbench (14.15)
starting vacuum...end.
Assertion failed: section != NULL, file prof_tree.c, line 528, function profile_node_iterator
Abort (core dumped)

root@jail04:~# mdb core
Loading modules: [ libumem.so.1 libc.so.1 ld.so.1 ]
> ::status
debugging core file of pgbench (64-bit) from jail04
file: /opt/local/bin/pgbench
initial argv: /opt/local/bin/pgbench -c 2 -j 2 -h 192.168.0.2 -U synapse synapse
threading model: native threads
status: process terminated by SIGABRT (Abort), pid=11238 uid=0 code=-1
libc panic message: Assertion failed: section != NULL, file prof_tree.c, line 528, function profile_node_iterator
> $C
fffffc7feed7cee0 libc.so.1`_lwp_kill+0xa()
fffffc7feed7cf10 libc.so.1`raise+0x22(6)
fffffc7feed7cf60 libc.so.1`abort+0x58()
fffffc7feed7d1d0 0xfffffc7fef066d62()
fffffc7feed7d270 0xfffffc7f9eef1e78()
fffffc7feed7d300 libkrb5.so.3.0.3`profile_iterator+0x113(fffffc7feed7d318, 0, fffffc7feed7d320)
fffffc7feed7d380 libkrb5.so.3.0.3`profile_get_value+0xd7(507d90, fffffc7feed7d3a0, fffffc7feed7d398)
fffffc7feed7d430 libkrb5.so.3.0.3`profile_get_boolean+0x68(507d90, fffffc7f9ef27c38, fffffc7f9ef274c2, 0, 0, fffffc7feed7d454)
fffffc7feed7d4c0 libkrb5.so.3.0.3`krb5_init_context_profile+0xf4(0, 0, fffffc7feed7d508)
fffffc7feed7d5d0 libgssapi_krb5.so.2.0.2`acquire_cred_from.isra.0+0xac()
fffffc7feed7d720 libgssapi_krb5.so.2.0.2`gss_add_cred_from+0x5b3(fffffc7feed7d7c4, 504790, 0, 504760, 1, 0)
fffffc7feed7d880 libgssapi_krb5.so.2.0.2`gss_acquire_cred_from+0x250(fffffc7feed7d90c, 0, 0, 0, 1, 0)
fffffc7feed7d8e0 libgssapi_krb5.so.2.0.2`gss_acquire_cred+0x20(fffffc7feed7d90c, 0, 0, 0, 1, fffffc7feed7d910)
fffffc7feed7d940 libpq.so.5.14`pg_GSS_have_cred_cache+0x49(4817e0)
fffffc7feed7e010 libpq.so.5.14`PQconnectPoll+0x14aa(481310)
fffffc7feed7e080 libpq.so.5.14`connectDBComplete+0x135(481310)
fffffc7feed7e0c0 libpq.so.5.14`PQconnectdbParams+0x38(fffffc7feed7e100, fffffc7feed7e140, 1)
fffffc7feed7e190 doConnect+0xe9()
fffffc7feed7efb0 threadRun+0x1e2(509ed8)
fffffc7feed7efe0 libc.so.1`_thrp_setup+0x77(fffffc7feeb70240)
fffffc7feed7eff0 libc.so.1`_lwp_start()
>

I'm new to OmniOS and pkgsrc, and I'm not a dev, so I have no more clue how to better debug it.... thanks for any suggestion about this.
I can confirm that there is no problem by using the PostgreSQL client installed from IPS. I tried with several versions of both PostgreSQL client and server. The problem seems to be reproducible: it happened on two different servers.

[jperkin]

Thanks, I'll take a look. The crash is coming from mit-krb5, and it doesn't look like the OmniOS packages enable GSS/KRB5 support, so that probably explains the difference.

[jperkin]

This turned out to be caused by an incorrect configure argument in our mit-krb5 build, and also explains why I was previously seeing a crash when using a different application. I've committed a fix for this now, and there should be an updated mit-krb5-1.21.3nb1 package available in the repository in due course.

[andrewhotlab]

Thank you so much. May I ask how much often upstream changes are committed to this fork of pkgsrc, and how often MNX rebuilds its package repository?

[jperkin]

I have GitHub actions that sync my feature trees every hour with upstream. Updates to the package repository are usually every few days, the limit is how fast I can build 25,000+ packages, and if updates trigger most packages then it can take around 2 days for the build to complete.

[andrewhotlab]

Thanks, the new package revision has just reached me via pkgin upgrade, and PGSQL client works nicely over pooled connections!