Thread: sqgfault on initdb with current CVS
Sorry about the length of this one, but I wanted to include backtrace
info. I've been getting a segfault when I try to setup a test version
of the current CVS tree, to run along beside a 'production' 6.5.X server.
This is how I've configured it:
wallace$./configure --prefix=/usr/local/pgsql7.0/ --with-pgport=6666 --enable-debug
After which make; make install works fine.
On my machine at home, where I can let pgsql take the default location
and port, I've had no trouble. With this one, at work, I get a segfault
when initdb tries to execute postgres in bootstrap mode. I've managed
to run postgres under gdb and capture a backtrace:
wallace$ which initdb
/usr/local/pgsql7.0/bin/initdb
wallace$ export | grep -i PG
declare -x LD_LIBRARY_PATH="/usr/local/pgsql7.0/lib"
declare -x PGDATA="/usr/local/pgsql7.0/data"
declare -x PGLIB="/usr/local/pgsql7.0/lib"
declare -x PWD="/extra/src/pgsql-current/src"
{PATH deleted}
{already ran initdb -d -n, then, after it failed, deleted
${PGDATA}/pg_control, and created an already sed processed version of
the template (just subs for PGUID) }
wallace$ gdb postgres
GNU gdb 19990928
<deleted banner>
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) set args -boot -x -C -F -D/usr/local/pgsql7.0/data -d template1 </home/reedstrm/template1.sql
(gdb) run
Starting program: /usr/local/pgsql7.0/bin/postgres -boot -x -C -F -D/usr/local/pgsql7.0/data -d template1
</home/reedstrm/template1.sql
<proname name>
<proowner int4>
<prolang oid>
<proisinh bool>
<proistrusted bool>
<proiscachable bool>
<pronargs int2>
<proretset bool>
<prorettype oid>
<proargtypes oidvector>
<probyte_pct int4>
<properbyte_cpu int4>
<propercall_cpu int4>
<prooutin_ratio int4>
<prosrc text>
<probin bytea>
> creating bootstrap relation
Program received signal SIGSEGV, Segmentation fault.
0x80eb266 in filepath (filename=0x81b2260 "pg_proc") at fd.c:529
529 len = strlen(DatabasePath) + strlen(filename) + 2;
(gdb) bt
#0 0x80eb26
#1 0x80eb456 in FileNameOpenFile (fileName=0x81b2260 "pg_proc", fileFlags=194, fileMode=384) at fd.c:657
#2 0x80f1d44 in mdcreate (reln=0x81b18b0) at md.c:128
#3 0x80f2da7 in smgrcreate (which=0, reln=0x81b18b0) at smgr.c:134
#4 0x8081a9d in heap_storage_create (rel=0x81b18b0) at heap.c:352
#5 0x8081a4c in heap_create (relname=0x81b8d48 "pg_proc", tupDesc=0x81bdd28, isnoname=0 '\000', istemp=0,
storage_create=1'\001') at heap.c:329
#6 0x807e95c in Int_yyparse () at bootparse.y:168
#7 0x8080557 in BootstrapMain (argc=7, argv=0xbffffc38) at bootstrap.c:395
#8 0x80afcee in main (argc=8, argv=0xbffffc34) at main.c:100
{grovel around in fd.c: looks like DatabasePath should be set by
SetDatabasePath, which uses ExpandDatabasePath to the value of DataDir +
dbName (template1) but somehow we missed it}
(gdb) print DatabasePath
$1 = 0x0
(gdb) print DataDir
$2 = 0xbffffd97 "/usr/local/pgsql7.0/data"
(gdb) exit
Anyone have any ideas? I can recreate at will.
Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005
> Sorry about the length of this one, but I wanted to include backtrace > info. I've been getting a segfault when I try to setup a test version > of the current CVS tree, to run along beside a 'production' 6.5.X server. > > This is how I've configured it: > > wallace$./configure --prefix=/usr/local/pgsql7.0/ --with-pgport=6666 --enable-debug For some reason, current does not seem to allow "." in the $PGDATA. I'm no sure why this happens at all. I guess it intends to inhibit "./" or "../" for a security reason? If so, that would be apparently an overkill. -- Tatsuo Ishii
On Tue, Mar 07, 2000 at 10:07:16AM +0900, Tatsuo Ishii wrote: > > Sorry about the length of this one, but I wanted to include backtrace > > info. I've been getting a segfault when I try to setup a test version > > of the current CVS tree, to run along beside a 'production' 6.5.X server. > > > > This is how I've configured it: > > > > wallace$./configure --prefix=/usr/local/pgsql7.0/ --with-pgport=6666 --enable-debug > > For some reason, current does not seem to allow "." in the > $PGDATA. I'm no sure why this happens at all. I guess it intends to > inhibit "./" or "../" for a security reason? If so, that would be > apparently an overkill. Thank you very much, Ishii-san, changing it to pgsql70 worked! If your ever in Houston, I owe you a beer! Ross -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005
> > wallace$./configure --prefix=/usr/local/pgsql7.0/ --with-pgport=6666 --enable-debug
> For some reason, current does not seem to allow "." in the
> $PGDATA. I'm no sure why this happens at all. I guess it intends to
> inhibit "./" or "../" for a security reason? If so, that would be
> apparently an overkill.
Bruce, can you add this item to the "must fix" list for the 7.0
release (hint hint - is it time to start that list?? ;)
Also, please add to the same list:
o implement the OVERLAPS date/time operator from SQL92 (Thomas)
o support TIME WITH TIME ZONE timezones in literals (Thomas)
o add support for full POSIX time zone specification (Thomas)
The POSIX time zone stuff is already in there, new for this release,
but needs to be polished to work with TZs away from GMT. The OVERLAPS
stuff is coded and being tested now; it just adds a few functions and
a bit of gram.y syntax.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
> > > wallace$./configure --prefix=/usr/local/pgsql7.0/ --with-pgport=6666 --enable-debug > > For some reason, current does not seem to allow "." in the > > $PGDATA. I'm no sure why this happens at all. I guess it intends to > > inhibit "./" or "../" for a security reason? If so, that would be > > apparently an overkill. > > Bruce, can you add this item to the "must fix" list for the 7.0 > release (hint hint - is it time to start that list?? ;) > > Also, please add to the same list: > > o implement the OVERLAPS date/time operator from SQL92 (Thomas) > o support TIME WITH TIME ZONE timezones in literals (Thomas) > o add support for full POSIX time zone specification (Thomas) > We don't have any must fixes for 7.0 yet. Why are these worthy? > The POSIX time zone stuff is already in there, new for this release, > but needs to be polished to work with TZs away from GMT. The OVERLAPS > stuff is coded and being tested now; it just adds a few functions and > a bit of gram.y syntax. Initdb required. You better get an OK from Marc. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Tue, 7 Mar 2000, Bruce Momjian wrote:
> > > > wallace$./configure --prefix=/usr/local/pgsql7.0/ --with-pgport=6666 --enable-debug
> > > For some reason, current does not seem to allow "." in the
> > > $PGDATA. I'm no sure why this happens at all. I guess it intends to
> > > inhibit "./" or "../" for a security reason? If so, that would be
> > > apparently an overkill.
> >
> > Bruce, can you add this item to the "must fix" list for the 7.0
> > release (hint hint - is it time to start that list?? ;)
>
> >
> > Also, please add to the same list:
> >
> > o implement the OVERLAPS date/time operator from SQL92 (Thomas)
> > o support TIME WITH TIME ZONE timezones in literals (Thomas)
> > o add support for full POSIX time zone specification (Thomas)
> >
>
>
> We don't have any must fixes for 7.0 yet. Why are these worthy?
>
> > The POSIX time zone stuff is already in there, new for this release,
> > but needs to be polished to work with TZs away from GMT. The OVERLAPS
> > stuff is coded and being tested now; it just adds a few functions and
> > a bit of gram.y syntax.
>
> Initdb required. You better get an OK from Marc.
Go for it ... no INITDBs after our first release candidate, but if these
are must-have's, we've only done one Beta1, so get it into Beta2...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org