Re: Segfault related to pg_authid when running initdb from git master
От | Peter Geoghegan |
---|---|
Тема | Re: Segfault related to pg_authid when running initdb from git master |
Дата | |
Msg-id | AANLkTinvsrF2SfbdSwX+HcHaJW5wQ3noK9Hhi0JxXWfk@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Segfault related to pg_authid when running initdb from git master (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Segfault related to pg_authid when running initdb from
git master
(Robert Haas <robertmhaas@gmail.com>)
|
Список | pgsql-hackers |
On 15 December 2010 16:26, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Dec 15, 2010 at 6:07 AM, Peter Geoghegan > <peter.geoghegan86@gmail.com> wrote: >> On 15 December 2010 01:35, Robert Haas <robertmhaas@gmail.com> wrote: >>> I am suspicious of the fact that you are invoking initdb as ./initdb. >>> Is it possible you're invoking this from the build tree, and there's >>> an installed copy out there that doesn't match, but is getting used? >>> Like maybe in /usr/local/pgsql/bin? >> >> No, I'm not doing that. I'm running initdb from /usr/local/pgsql/bin >> (nothing pg related can be found in my $PATH), but it's the only copy >> on my system, which was installed from git master last night. It has >> debugging symbols, and I've actually re-created this from initdb's >> point of view within GDB with source level debugging. > > Well, something's clearly funky here because your initdb has debugging > symbols but your postgres executable does not. I may be missing > something obvious, but I don't see how that can happen without mixing > up two different builds. Just to make sure that I'm not going crazy, I did a git pull, rebuilt pg passing --enable-debug and --enable-casssert to configure as before, followed by make && make install. Then I tried this: [peter@peter bin]$ pwd /usr/local/pgsql/bin [peter@peter bin]$ ls -l total 7720 -rwxr-xr-x. 1 root root 53977 Dec 15 16:47 clusterdb -rwxr-xr-x. 1 root root 55058 Dec 15 16:47 createdb -rwxr-xr-x. 1 root root 58351 Dec 15 16:47 createlang -rwxr-xr-x. 1 root root 58036 Dec 15 16:47 createuser -rwxr-xr-x. 1 root root 53380 Dec 15 16:47 dropdb -rwxr-xr-x. 1 root root 62052 Dec 15 16:47 droplang -rwxr-xr-x. 1 root root 53382 Dec 15 16:47 dropuser -rwxr-xr-x. 1 root root 707190 Dec 15 16:47 ecpg -rwxr-xr-x. 1 root root 123447 Dec 15 16:47 initdb -rwxr-xr-x. 1 root root 26435 Dec 15 16:47 pg_config -rwxr-xr-x. 1 root root 25229 Dec 15 16:47 pg_controldata -rwxr-xr-x. 1 root root 73784 Dec 15 16:47 pg_ctl -rwxr-xr-x. 1 root root 301781 Dec 15 16:47 pg_dump -rwxr-xr-x. 1 root root 75323 Dec 15 16:47 pg_dumpall -rwxr-xr-x. 1 root root 32015 Dec 15 16:47 pg_resetxlog -rwxr-xr-x. 1 root root 131867 Dec 15 16:47 pg_restore -rwxr-xr-x. 1 root root 91006 Dec 6 11:34 pg_upgrade -rwxr-xr-x. 1 root root 5380671 Dec 15 16:47 postgres lrwxrwxrwx. 1 root root 8 Dec 15 16:47 postmaster -> postgres -rwxr-xr-x. 1 root root 398677 Dec 15 16:47 psql -rwxr-xr-x. 1 root root 55257 Dec 15 16:47 reindexdb -rwxr-xr-x. 1 root root 32410 Dec 15 16:47 vacuumdb [peter@peter bin]$ which postgres /usr/bin/which: no postgres in (/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/peter/bin) [peter@peter bin]$ which initdb /usr/bin/which: no initdb in (/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/peter/bin) Observe that the initdb and postgres timestamps are the same. This laptop is less than 2 weeks old, and has never had any postgres packages installed on it. I can once again reproduce the problem, exactly as before. My postgres executable does have debugging symbols, just less than initdb (I'm not sure what the exact term is, but it just lacks line information while having some debugging symbols). >> I cannot find the coredump. Perhaps it's a permissions issue. What do you think? > > It would presumably get dumped into the data directory. So if > --noclean isn't used I expect it'll get nuked. It isn't there...it just looks like a virginal PGDATA directory. > Ugh. Maybe someone smarter can figure out what that means, but I have > no clue. _bt_preprocess_keys() is a pretty good-sized function; > there's no obvious way to know which pointer reference is blowing up > without line-number information. That's a pity, because I don't have a clue how to get line number information. I could always try printf() debugging, but I really shouldn't have to. -- Regards, Peter Geoghegan
В списке pgsql-hackers по дате отправления: