Re: Segfault related to pg_authid when running initdb from git master - Mailing list pgsql-hackers

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.

>> Can you fire up gdb on this core dump, using "gdb
>> /usr/local/pgsql/bin/postgres /path/to/coredump"?  Or, another
>> possibility is to run initdb with --noclean and then run the command,
>> without routing the output to /dev/null:
>>
>> /usr/local/pgsql/bin/postgres" --single -F -O -c
>> search_path=pg_catalog -c exit_on_error=true template1
>
> 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.

> Anyway, I have produced a useful backtrace by debugging postgres
> directly after running initdb with --noclean as described:
>
> [peter@peter bin]$ /usr/local/pgsql/bin/postgres --single -F -O -c
> search_path=pg_catalog -c exit_on_error=true template1
> Segmentation fault
> [peter@peter bin]$ gdb postgres
> GNU gdb (GDB) Fedora (7.2-26.fc14)
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/local/pgsql/bin/postgres...done.
> (gdb) set args --single -F -O -c search_path=pg_catalog -c
> exit_on_error=true template1
> (gdb) start
> Temporary breakpoint 1 at 0x577360
> Starting program: /usr/local/pgsql/bin/postgres --single -F -O -c
> search_path=pg_catalog -c exit_on_error=true template1
>
> Temporary breakpoint 1, 0x0000000000577360 in main ()
> (gdb) c
> Continuing.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x000000000047615b in _bt_preprocess_keys ()
> (gdb) bt
> #0  0x000000000047615b in _bt_preprocess_keys ()
> #1  0x0000000000475382 in _bt_first ()
> #2  0x0000000000473d71 in btgettuple ()
> #3  0x00000000006ba67c in FunctionCall2 ()
> #4  0x000000000046e08a in index_getnext ()
> #5  0x000000000046d556 in systable_getnext ()
> #6  0x00000000006a92bf in LookupOpclassInfo ()
> #7  0x00000000006a9a58 in RelationInitIndexAccessInfo ()
> #8  0x00000000006aa9cb in RelationBuildDesc ()
> #9  0x00000000006aabfd in load_critical_index ()
> #10 0x00000000006ac12a in RelationCacheInitializePhase3 ()
> #11 0x00000000006c19ca in InitPostgres ()
> #12 0x000000000060058f in PostgresMain ()
> #13 0x000000000057774d in main ()

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company