[ADMIN] exit code 139 performing initdb (pg 9.1 on linux)

[Gunthard Stübs]

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

[Tom Lane]

Post by Gunthard Stübs
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
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

[Gunthard Stübs]

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

[Gunthard Stübs]

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

[Tom Lane]

Post by Gunthard Stübs
#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

[Tom Lane]

Post by Tom Lane
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