Thread: initdb failing on REL9_5_STABLE with exit code 132...

Hello,

I just built REL9_5_STABLE using an embedded Linux install 4.1.8.

I configured as follows:  configure --with-python --with-openssl
--enable-debug

When I run initdb, I get the following:

creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
creating template1 database in /usr/local/pgsql/data/base/1 ... ok
initializing pg_authid ... ok
initializing dependencies ... ok
creating system views ... ok
loading system objects' descriptions ... sh: line 1: 19593 Illegal
instruction     "/usr/local/pgsql/bin/postgres" --single -F -O -c
search_path=pg_catalog -c exit_on_error=true template1 > /dev/null
child process exited with exit code 132

I'm going to try to rebuild now without my configure options and retry.
Any tips on hunting this down will be appreciated.

Thanks

Bob

Bob Cochran <pgsql@mindchasers.com> writes:
> I just built REL9_5_STABLE using an embedded Linux install 4.1.8.

> I configured as follows:  configure --with-python --with-openssl
> --enable-debug

> When I run initdb, I get the following:

> creating subdirectories ... ok
> selecting default max_connections ... 100
> selecting default shared_buffers ... 128MB
> selecting dynamic shared memory implementation ... posix
> creating configuration files ... ok
> creating template1 database in /usr/local/pgsql/data/base/1 ... ok
> initializing pg_authid ... ok
> initializing dependencies ... ok
> creating system views ... ok
> loading system objects' descriptions ... sh: line 1: 19593 Illegal
> instruction     "/usr/local/pgsql/bin/postgres" --single -F -O -c
> search_path=pg_catalog -c exit_on_error=true template1 > /dev/null
> child process exited with exit code 132

Hm, not much to go on there.  In the past, when we've seen crashes at
this stage, it's frequently meant a compiler bug or at least over-
aggressive optimization.  If you're using a bleeding-edge compiler
it might be worth backing off the -O level to see what happens.

            regards, tom lane

On 07/01/2016 03:34 PM, Tom Lane wrote:
> Bob Cochran <pgsql@mindchasers.com> writes:
>> I just built REL9_5_STABLE using an embedded Linux install 4.1.8.
>> I configured as follows:  configure --with-python --with-openssl
>> --enable-debug
>> When I run initdb, I get the following:
>> creating subdirectories ... ok
>> selecting default max_connections ... 100
>> selecting default shared_buffers ... 128MB
>> selecting dynamic shared memory implementation ... posix
>> creating configuration files ... ok
>> creating template1 database in /usr/local/pgsql/data/base/1 ... ok
>> initializing pg_authid ... ok
>> initializing dependencies ... ok
>> creating system views ... ok
>> loading system objects' descriptions ... sh: line 1: 19593 Illegal
>> instruction     "/usr/local/pgsql/bin/postgres" --single -F -O -c
>> search_path=pg_catalog -c exit_on_error=true template1 > /dev/null
>> child process exited with exit code 132
> Hm, not much to go on there.  In the past, when we've seen crashes at
> this stage, it's frequently meant a compiler bug or at least over-
> aggressive optimization.  If you're using a bleeding-edge compiler
> it might be worth backing off the -O level to see what happens.

Thank you Tom.  I re-ran configure with "CFLAGS=-Wall .... -O0", and I
was able to successfully run initdb and start the server.

Prior to this, the optimization level was set as O2, and initdb would
fail with error code 132.

So, I can both move forward on my target system, and I suppose I know
now there is a compiler issue.   I'll report back if I get some more
info and it's relevant to postgres.

BTW, I'm building on a powerpc64 target with a Yocto-built rootfs from a
master-next branch, so it's sort of on the edge.

Bob



>
>             regards, tom lane
>