Thread: BUG #16782: initdb coredump post-bootstrap initialization

The following bug has been logged on the website:

Bug reference:      16782
Logged by:          Ming HU
Email address:      humings@gmail.com
PostgreSQL version: 12.0
Operating system:   Centos 7 (Linux 3.10.0-229.el7.x86_64)
Description:

1. log
-bash-4.2$ initdb
The files belonging to this database system will be owned by user
"huming02".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

creating directory /opt/home/huming02/postgresql-12.0/demodb ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... PRC
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... sh: line 1: 114793 Segmentation
fault      (core dumped) "/opt/home/huming02/postgresql-12.0/bin/postgres"
--single -F -O -j -c search_path=pg_catalog -c exit_on_error=true template1
> /dev/null
child process exited with exit code 139
initdb: removing data directory
"/opt/home/huming02/postgresql-12.0/demodb"

2. backtrace of coredump
(gdb) bt
#0  pg_detoast_datum (datum=0x100000000) at fmgr.c:1741
#1  0x0000000000808b63 in json_object (fcinfo=<optimized out>) at
json.c:2291
#2  0x00007f5a4b8b70bd in parse_value () from /lib64/libjansson.so.4
#3  0x00007f5a4b8b74f6 in parse_json () from /lib64/libjansson.so.4
#4  0x00007f5a4b8b7693 in json_loads () from /lib64/libjansson.so.4
#5  0x00007f5a4bac1ccc in nss_request () from /lib64/libnss_http.so.2
#6  0x00007f5a4bac22f3 in _nss_http_getpwuid_r_locked () from
/lib64/libnss_http.so.2
#7  0x00007f5a4bac23c7 in _nss_http_getpwuid_r () from
/lib64/libnss_http.so.2
#8  0x00007f5a524c052e in getpwuid_r@@GLIBC_2.2.5 () from /lib64/libc.so.6
#9  0x00007f5a524bfc66 in getpwuid () from /lib64/libc.so.6
#10 0x00000000008fecba in get_user_name (errstr=errstr@entry=0x7fff2f037a18)
at username.c:40
#11 0x00000000008fed12 in get_user_name_or_exit (progname=0x27ed010
"postgres") at username.c:79
#12 0x0000000000480107 in main (argc=10, argv=0x27ee0d0) at main.c:226

PG Bug reporting form <noreply@postgresql.org> writes:
> (gdb) bt
> #0  pg_detoast_datum (datum=0x100000000) at fmgr.c:1741
> #1  0x0000000000808b63 in json_object (fcinfo=<optimized out>) at
> json.c:2291
> #2  0x00007f5a4b8b70bd in parse_value () from /lib64/libjansson.so.4
> #3  0x00007f5a4b8b74f6 in parse_json () from /lib64/libjansson.so.4
> #4  0x00007f5a4b8b7693 in json_loads () from /lib64/libjansson.so.4
> #5  0x00007f5a4bac1ccc in nss_request () from /lib64/libnss_http.so.2
> #6  0x00007f5a4bac22f3 in _nss_http_getpwuid_r_locked () from
> /lib64/libnss_http.so.2
> #7  0x00007f5a4bac23c7 in _nss_http_getpwuid_r () from
> /lib64/libnss_http.so.2
> #8  0x00007f5a524c052e in getpwuid_r@@GLIBC_2.2.5 () from /lib64/libc.so.6
> #9  0x00007f5a524bfc66 in getpwuid () from /lib64/libc.so.6
> #10 0x00000000008fecba in get_user_name (errstr=errstr@entry=0x7fff2f037a18)
> at username.c:40
> #11 0x00000000008fed12 in get_user_name_or_exit (progname=0x27ed010
> "postgres") at username.c:79
> #12 0x0000000000480107 in main (argc=10, argv=0x27ee0d0) at main.c:226

Hm.  If this stack trace is to be believed (something always a bit worth
questioning), then this must be a bug in libjansson.  That surely should
not be calling into random PG code.

A likely bet given the function names we see here is that
(a) "json_object" is the name of a function in libjansson as well as of
one in core Postgres, and
(b) when libjansson tries to call its function, the dynamic linker
redirects that call to the one in the host application.

I believe it's possible for (b) to be prevented if appropriate options are
used when building the library, but I do not recall details ATM.  In any
case you'd need to file a bug with the jansson package maintainer to get
it fixed.

It's interesting that we have not heard of this issue before.  I suppose
that you are running with some nonstandard stuff installed --- on my
RHEL8 box, for example, there's no libnss_http.so at all.

            regards, tom lane