Skip site navigation (1) Skip section navigation (2)

Re: 7.2.1 segfaults.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Amadei <amadei(at)dandy(dot)net>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: 7.2.1 segfaults.
Date: 2002-05-04 14:48:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Stephen Amadei <amadei(at)dandy(dot)net> writes:
> #0 0x255843 in strncpy (s1=0xbfffead0 "n\013", s2=0x8213414 "n\013",
>    n=4294967292) at ../sysdeps/generic/strncpy.c:82
> #1 0x81516ab in GetRawDatabaseInfo ()
> #2 0x81511fb in InitPostgres ()

Hmm.  It looks like GetRawDatabaseInfo is reading a zero for the VARSIZE
of datpath, and then computing -4 (which strncpy will take as a huge
unsigned value) as the string length to copy.  You could try applying
a patch like this, in src/backend/utils/misc/database.c (about line
225 in current sources):

                /* Found it; extract the OID and the database path. */
                *db_id = tup.t_data->t_oid;
                pathlen = VARSIZE(&(tup_db->datpath)) - VARHDRSZ;
+               if (pathlen < 0)
+                   pathlen = 0;                /* pure paranoia */
                if (pathlen >= MAXPGPATH)
                    pathlen = MAXPGPATH - 1;    /* pure paranoia */
                strncpy(path, VARDATA(&(tup_db->datpath)), pathlen);
                path[pathlen] = '\0';

However this really shouldn't be needed; I'm wondering whether the
database's row in pg_database has been clobbered somehow.  If so,
it probably won't get much further before dying.

Two questions: does the same thing happen for all available databases?
Have you tried to create a database with a nonstandard location
(nondefault datpath)?

			regards, tom lane

In response to


pgsql-bugs by date

Next:From: Tom LaneDate: 2002-05-04 14:53:55
Subject: Re: Why does Postgres need the /bin/sh?
Previous:From: Stephen AmadeiDate: 2002-05-04 04:32:11
Subject: Re: Why does Postgres need the /bin/sh?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group