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

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.

> 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?

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 ()

For some reason, postgres has limited debugging symbols (no line
number information is available). Given that it is available from
initdb, that seems very odd:



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) n
Single stepping until exit from function main,
which has no line number information.

Program received signal SIGSEGV, Segmentation fault.
0x000000000047615b in _bt_preprocess_keys ()



Hope that helps.

--
Regards,
Peter Geoghegan