Thread: exit code 139 performing initdb (pg 9.1 on linux)
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
=?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
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
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
=?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
=?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