initdb segfault - solaris 8

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