Thread: BUG #18082: coredump during initdb

The following bug has been logged on the website:

Bug reference:      18082
Logged by:          Duke Astar
Email address:      dukeastar@gmail.com
PostgreSQL version: 13.10
Operating system:   Linux x86
Description:

Operating system: CentOS release 5.8 (Final) - Linux dev-linuxx86
2.6.18-308.el5 #1 SMP Tue Feb 21 20:05:41 EST 2012 i686 i686 
Build options: from source code using default options for 'configure' 

Command line to reproduce bug: initdb  -A trust -E UTF8 --locale=C -U
"dbuser" -D /home/dbuser/db

Callstack:

==7764==
==7764== Process terminating with default action of signal 11 (SIGSEGV)
==7764==  Access not within mapped region at address 0xC
==7764==    at 0x8337DDA: compare_pathkeys (in
/home/devuser/pgdbg/32/pg-13.10.rel/bin/postgres)
==7764==    by 0x8365F13: add_path (in
/home/devuser/pgdbg/32/pg-13.10.rel/bin/postgres)
==7764==    by 0x83331DE: get_index_paths (in
/home/devuser/pgdbg/32/pg-13.10.rel/bin/postgres)
==7764==    by 0x8333767: create_index_paths (in
/home/devuser/pgdbg/32/pg-13.10.rel/bin/postgres)
==7764==    by 0x83260B9: set_rel_pathlist (in
/home/devuser/pgdbg/32/pg-13.10.rel/bin/postgres)
==7764==    by 0x832650D: make_one_rel (in
/home/devuser/pgdbg/32/pg-13.10.rel/bin/postgres)
==7764==    by 0x83456B8: query_planner (in
/home/devuser/pgdbg/32/pg-13.10.rel/bin/postgres)
==7764==    by 0x834BEE5: grouping_planner (in
/home/devuser/pgdbg/32/pg-13.10.rel/bin/postgres)
==7764==    by 0x834D900: subquery_planner (in
/home/devuser/pgdbg/32/pg-13.10.rel/bin/postgres)
==7764==    by 0x834E6BE: standard_planner (in
/home/devuser/pgdbg/32/pg-13.10.rel/bin/postgres)
==7764==    by 0x84117F8: pg_plan_query (in
/home/devuser/pgdbg/32/pg-13.10.rel/bin/postgres)
==7764==    by 0x84118AE: pg_plan_queries (in
/home/devuser/pgdbg/32/pg-13.10.rel/bin/postgres)
==7764==  If you believe this happened as a result of a stack
==7764==  overflow in your program's main thread (unlikely but
==7764==  possible), you can try to increase the size of the
==7764==  main thread stack using the --main-stacksize= flag.
==7764==  The main thread stack size used in this run was 10485760.
==7764==

Workaround:
To make initdb work as expected I use CFLAGS=O instead of default O2
optimization.
I think optimizer, break something in MACRO 'forboth' or
'multi_for_advance_cell'

Another option is to add code before call to forboth in compare_pathkeys (
cf below)

    if(keys2 == NULL)
        return PATHKEYS_BETTER1;
    if(keys1 == NULL)
        return PATHKEYS_BETTER2;
    
I don't know, if's a compiler issue or not.
In postgres 9.6, I know it's very old, the problem was not present, but I
saw that the handling of linked list was re-written on current version.
This problem is present in 13.2, 13.10, 13.12, 14.9. I don't try on 15
version

I let you decide if it s to defined as a bug or not, maybe a recommandation
to put CFLAGS options to -O on olders systems.

Thanks 
Regards

PG Bug reporting form <noreply@postgresql.org> writes:
> Operating system: CentOS release 5.8 (Final) - Linux dev-linuxx86
> 2.6.18-308.el5 #1 SMP Tue Feb 21 20:05:41 EST 2012 i686 i686 

So I suppose your compiler is also a dozen years old?

I don't see any good reason to think this isn't a compiler bug.
If you can't upgrade to a newer compiler version, backing off the
default optimization level is probably your best option.  But we
don't test or support operating systems that old.

            regards, tom lane