Thread: initdb segfault - solaris 8
The bug site is down, so I thought I would ask here:
% gmake check
[...]
1 of 76 tests failed.
% initdb -D /home/postgres/db
This database system will be initialized with username "postgres".
This user will own all the data files and must also own the server process.
Creating directory /home/postgres/db
Creating directory /home/postgres/db/base
Creating directory /home/postgres/db/global
Creating directory /home/postgres/db/pg_xlog
Creating template1 database in /home/postgres/db/base/1
DEBUG: database system was shut down at 2001-10-25 22:07:12 PDT
DEBUG: CheckPoint record at (0, 8)
DEBUG: Redo record at (0, 8); Undo record at (0, 8); Shutdown TRUE
DEBUG: NextTransactionId: 514; NextOid: 16384
DEBUG: database system is in production state
a2Creating global relations in /home/postgres/db/global
DEBUG: database system was shut down at 2001-10-25 22:07:19 PDT
DEBUG: CheckPoint record at (0, 108)
DEBUG: Redo record at (0, 108); Undo record at (0, 0); Shutdown TRUE
DEBUG: NextTransactionId: 514; NextOid: 17199
DEBUG: database system is in production state
Initializing pg_shadow.
Segmentation Fault - core dumped
initdb failed.
% gdb =postgres core
#0 0x81abdca in ValidateBinary ()
(gdb) where
#0 0x81abdca in ValidateBinary ()
#1 0x81ac024 in FindExec ()
#2 0x8152291 in PostgresMain ()
#3 0x81029b1 in main ()
#4 0x806d8c3 in _start ()
% cat /etc/release
Solaris 8 7/01 s28x_u5wos_08 INTEL
Copyright 2001 Sun Microsystems, Inc. All Rights Reserved.
Assembled 06 June 2001
Any ideas?
-Seth
sjh@ucf.ics.uci.edu writes:
> [ coredump in ValidateBinary ]
It's hard to see how ValidateBinary could dump core, unless perhaps its
idea of struct stat, struct group or struct passwd is different from the
system's. I'd suggest checking for conflicting system headers.
If no dice, try recompiling with --enable-debug so that you can get more
info with gdb.
regards, tom lane
> sjh@ucf.ics.uci.edu writes:
> > [ coredump in ValidateBinary ]
>
> It's hard to see how ValidateBinary could dump core, unless perhaps its
> idea of struct stat, struct group or struct passwd is different from the
> system's. I'd suggest checking for conflicting system headers.
>
> If no dice, try recompiling with --enable-debug so that you can get more
> info with gdb.
>
> regards, tom lane
Here is the stack trace w/ --enable-debug
#0 0x81cd6ba in ValidateBinary (
path=0x804718c "/pkg/postgresql-7.1.3/bin/postgres") at findbe.c:115
#1 0x81cd914 in FindExec (full_path=0x8278d40 "",
argv0=0x8047794 "/pkg/postgresql-7.1.3/bin/postgres",
binary_name=0x8223a73 "postgres") at findbe.c:184
#2 0x817204d in PostgresMain (argc=7, argv=0x8047664, real_argc=7,
real_argv=0x8047664, username=0x8287838 "postgres") at postgres.c:1617
#3 0x811d07d in main (argc=7, argv=0x8047664) at main.c:196
(gdb) print *pwp
$2 = {pw_name = 0x8284bb0 "postgres", pw_passwd = 0x8284faf "", pw_uid = 666,
pw_gid = 303, pw_age = 0x8284faf "", pw_comment = 0x8284faf "",
pw_gecos = 0x8284bc8 "postgres", pw_dir = 0x8284bb9 "/home/postgres",
pw_shell = 0x8284bd1 "/bin/zsh"}
(gdb) print i
$3 = 0
(gdb) print *gp
$5 = {gr_name = 0x838d39c "shared", gr_passwd = 0x0, gr_gid = 305,
gr_mem = 0x0}
struct group {
char *gr_name; /* the name of the group */
char *gr_passwd; /* the encrypted group password */
gid_t gr_gid; /* the numerical group ID */
char **gr_mem; /* vector of pointers to member names */
};
Well, gr_mem is null. Not sure why, but that has to be it.
-Seth
sjh@ucf.ics.uci.edu writes:
> Here is the stack trace w/ --enable-debug
> #0 0x81cd6ba in ValidateBinary (
> path=0x804718c "/pkg/postgresql-7.1.3/bin/postgres") at findbe.c:115
Well, that narrows it down to a problem with the "struct group" returned
by getgrgid() ... but the code is correct according to the man page I
have here for getgrgid. You're going to have to dig further on your
own.
FWIW, I'd still wonder about whether the definition of "struct group"
seen by Postgres agrees with what libc thinks.
BTW: you wouldn't be getting into this code if the executable were owned
by the postgres user. So if you can't figure it out, a workaround
should be to change the ownership.
regards, tom lane
> sjh@ucf.ics.uci.edu writes: > > Here is the stack trace w/ --enable-debug > > > #0 0x81cd6ba in ValidateBinary ( > > path=0x804718c "/pkg/postgresql-7.1.3/bin/postgres") at findbe.c:115 > > Well, that narrows it down to a problem with the "struct group" returned > by getgrgid() ... but the code is correct according to the man page I > have here for getgrgid. You're going to have to dig further on your > own. > > FWIW, I'd still wonder about whether the definition of "struct group" > seen by Postgres agrees with what libc thinks. I think it's a bug in the solaris 8 LDAP NSS module that returns a null gr_mem. But, it's also poor form to use gr_mem before checking it... -Seth
> > sjh@ucf.ics.uci.edu writes: > > > Here is the stack trace w/ --enable-debug > > > > > #0 0x81cd6ba in ValidateBinary ( > > > path=0x804718c "/pkg/postgresql-7.1.3/bin/postgres") at findbe.c:115 > > > > Well, that narrows it down to a problem with the "struct group" returned > > by getgrgid() ... but the code is correct according to the man page I > > have here for getgrgid. You're going to have to dig further on your > > own. > > > > FWIW, I'd still wonder about whether the definition of "struct group" > > seen by Postgres agrees with what libc thinks. > > I think it's a bug in the solaris 8 LDAP NSS module that returns > a null gr_mem. But, it's also poor form to use gr_mem before checking > it... You got us. :-) I have added code to check for a NULL return from getgrgid(). -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 Index: src/backend/utils/init/findbe.c =================================================================== RCS file: /cvsroot/pgsql/src/backend/utils/init/findbe.c,v retrieving revision 1.23 diff -c -r1.23 findbe.c *** src/backend/utils/init/findbe.c 2001/10/21 03:43:54 1.23 --- src/backend/utils/init/findbe.c 2001/10/29 17:51:36 *************** *** 103,109 **** if (pwp->pw_gid == buf.st_gid) ++in_grp; else if (pwp->pw_name && ! (gp = getgrgid(buf.st_gid))) { for (i = 0; gp->gr_mem[i]; ++i) { --- 103,109 ---- if (pwp->pw_gid == buf.st_gid) ++in_grp; else if (pwp->pw_name && ! (gp = getgrgid(buf.st_gid)) != NULL) { for (i = 0; gp->gr_mem[i]; ++i) {