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 по дате отправления:

Предыдущее
От: Dmitriy Igrishin
Дата:
Сообщение: Re: hstores in pl/python
Следующее
От: Florian Pflug
Дата:
Сообщение: Re: hstores in pl/python