Re: Segfault related to pg_authid when running initdb from git master

On 15 December 2010 16:26, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Dec 15, 2010 at 6:07 AM, Peter Geoghegan
> <peter(dot)geoghegan86(at)gmail(dot)com> wrote:
>> On 15 December 2010 01:35, Robert Haas <robertmhaas(at)gmail(dot)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(at)peter bin]$ pwd
/usr/local/pgsql/bin
[peter(at)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(at)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(at)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