Thread: exit code 139 performing initdb (pg 9.1 on linux)

exit code 139 performing initdb (pg 9.1 on linux)

From
Gunthard Stübs
Date:
Hi all,

I am new to pg linux administration and this list.

I installed v9.1 on linux (older suse distr.) from source code using
configure --without-readline (in case that it is important).

performing initdb --locale=de_DE.UTF-8 -D /usr/local/pgsql/data/ everything
run fine until:
vacuuming database template1 ... ok
copying template1 to template0 ... child process exited with exit code 139
initdb: removing contents of data directory "/usr/local/pgsql/data"

I have no idea how to fix that nor did I find any information for exit code
139 on the internet (using google :-).

I would greatly appreciate any clue to solve that problem.

Best regards,
Gunthard

Re: exit code 139 performing initdb (pg 9.1 on linux)

From
Tom Lane
Date:
=?ISO-8859-1?Q?Gunthard_St=FCbs?= <stuebs2009@gmx.de> writes:
> I installed v9.1 on linux (older suse distr.) from source code using
> configure --without-readline (in case that it is important).

> performing initdb --locale=de_DE.UTF-8 -D /usr/local/pgsql/data/ everything
> run fine until:
> vacuuming database template1 ... ok
> copying template1 to template0 ... child process exited with exit code 139
> initdb: removing contents of data directory "/usr/local/pgsql/data"

Hmm, that's pretty interesting.  Exit code 139 is presumably a SIGSEGV,
but it's surprising that it would get that far and then crash.

Please (1) rebuild with --enable-cassert and --enable-debug configure
options, if you didn't already; (2) set "ulimit -c unlimited" if that's
not the default in your environment; (3) run initdb with the --noclean
option; (4) look into /usr/local/pgsql/data to find the core file left
behind by the crash, and do
    $ gdb /usr/local/bin/postgres /path/to/core-file
    gdb> bt
    gdb> quit
(5) post the output of "bt" here.

BTW, what compiler version are you using exactly, and what compiler options?

            regards, tom lane

Re: exit code 139 performing initdb (pg 9.1 on linux)

From
Gunthard Stübs
Date:
Tom,

thanks for your quick response.
as mentioned the linux is rather old (~ 7 years) and i know that some
software is not up to date. (but the admin has no time to update the entire
system)

i don't know what you mean with compiler options. if i enter gcc -v it lists:
Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.1/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib
--enable-languages=c,c++,f77,objc,java,ada --disable-checking
--enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux
Thread model: posix
gcc version 3.3.1 (SuSE Linux)

I rebuild pg with the settings you suggested. the bt dump is 1655 lines of
hexcode and i am not sure whether i should post all here. it starts with:

#0  0x00000009 in ?? ()
#1  0x00000000 in ?? ()
#2  0x0000e000 in ?? ()
#3  0x082676a1 in ?? ()
#4  0x00000009 in ?? ()
#5  0x00000000 in ?? ()
#6  0x00000000 in ?? ()
#7  0x0000e000 in ?? ()
#8  0x00000000 in ?? ()
#9  0x00000004 in ?? ()
#10 0x00000180 in ?? ()
#11 0x00000008 in ?? ()
#12 0x0853bd1c in ?? ()
and ends with
#1648 0x6c2f7273 in ?? ()
#1649 0x6c61636f in ?? ()
#1650 0x7367702f in ?? ()
#1651 0x622f6c71 in ?? ()
#1652 0x702f6e69 in ?? ()
#1653 0x6774736f in ?? ()
#1654 0x00736572 in ?? ()
#1655 0x00000000 in ?? ()
Cannot access memory at address 0xc0000000

of course i will send you the full file.

best regards,
gunthard

Re: exit code 139 performing initdb (pg 9.1 on linux)

From
Gunthard Stübs
Date:
sorry, I first used for gdb the pg path Tom wrote and not my own one...

the correct backtrace looks like this:

#3  0x082676a1 in pg_flush_data (fd=9, offset=0, amount=57344) at fd.c:335
#4  0x0826ab02 in copy_file (fromfile=0xbfffeb90 "base/1/12051",
tofile=0xbfffe790 "base/12277/12051")
     at copydir.c:205
#5  0x0826a743 in copydir (fromdir=0x85f26ec "base/1", todir=0x85f4dbc
"base/12277", recurse=0 '\0')
     at copydir.c:95
#6  0x08169b6b in createdb (stmt=0x4b) at dbcommands.c:587
#7  0x0828d761 in PortalRunUtility (portal=0x85f055c, utilityStmt=0x85acae8,
isTopLevel=1 '\001',
     dest=0x84f0058, completionTag=0xbffff3f0 "") at pquery.c:1184
#8  0x0828d865 in PortalRunMulti (portal=0x85f055c, isTopLevel=1 '\001',
dest=0x84f0058,
     altdest=0x84f0058, completionTag=0xbffff3f0 "") at pquery.c:1322
#9  0x0828d1b1 in PortalRun (portal=0x85f055c, count=2147483647,
isTopLevel=1 '\001', dest=0x84f0058,
     altdest=0x84f0058, completionTag=0xbffff3f0 "") at pquery.c:813
#10 0x082881b3 in exec_simple_query (query_string=0x85ac19c "CREATE DATABASE
template0;\n")
     at postgres.c:1018
#11 0x0828bcb3 in PostgresMain (argc=9, argv=0xbffff550,
     username=0x85ac19c "CREATE DATABASE template0;\n") at postgres.c:3926
#12 0x081e3051 in main (argc=9, argv=0x85373d8) at main.c:197

I would be glad to know whether there is a chance to get pg running under
these conditions or whether maybe i should upgrade gcc or 'downgrade' pg.

best regards,
gunthard

Re: exit code 139 performing initdb (pg 9.1 on linux)

From
Tom Lane
Date:
=?ISO-8859-1?Q?Gunthard_St=FCbs?= <stuebs2009@gmx.de> writes:
> the correct backtrace looks like this:

> #3  0x082676a1 in pg_flush_data (fd=9, offset=0, amount=57344) at fd.c:335
> #4  0x0826ab02 in copy_file (fromfile=0xbfffeb90 "base/1/12051",
> tofile=0xbfffe790 "base/12277/12051")
>      at copydir.c:205
> #5  0x0826a743 in copydir (fromdir=0x85f26ec "base/1", todir=0x85f4dbc
> "base/12277", recurse=0 '\0')
>      at copydir.c:95

Thanks for doing the legwork.  Line 335 of fd.c is

    return posix_fadvise(fd, offset, amount, POSIX_FADV_DONTNEED);

which means you've got one of those nasty Linux versions that claims to
have posix_fadvise but it dumps core when executed.  As a workaround
you can comment out "#define USE_POSIX_FADVISE" in
src/include/pg_config_manual.h before building.

What kernel and glibc versions are you running, exactly?

            regards, tom lane

Re: exit code 139 performing initdb (pg 9.1 on linux)

From
Tom Lane
Date:
=?ISO-8859-1?Q?Gunthard_St=FCbs?= <stuebs2009@gmx.de> writes:
>> What kernel and glibc versions are you running, exactly?

> Linux version 2.4.21-266-default
> GNU C Library stable release version 2.3.2 (20030827)

Yeah, we've seen this before.  What it boils down to is that kernels
prior to 2.6.x don't have posix_fadvise but older versions of glibc
think they do.  Some googling says that was fixed in glibc 2.3.5-3,
so probably updating to that or later would be the simplest solution.

(It also seems the bug is specific to 64-bit builds, but I doubt
you want to fall back to a 32-bit build of Postgres.)

            regards, tom lane