On Sat, 4 May 2002, Tom Lane wrote:
> 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/m
Stephen Amadei <[EMAIL PROTECTED]> 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 zer
On Fri, 3 May 2002, Tom Lane wrote:
> Stephen Amadei <[EMAIL PROTECTED]> writes:
> >> Urgh. Can you provide a stack trace?
>
> > You mean using strace? Yeah. The strace created quite a bit of logs, but
> > the process that segfaulted is included below.
>
> > open("/usr/local/pgsql/data/global/
Stephen Amadei <[EMAIL PROTECTED]> writes:
>> Urgh. Can you provide a stack trace?
> You mean using strace? Yeah. The strace created quite a bit of logs, but
> the process that segfaulted is included below.
> open("/usr/local/pgsql/data/global/1262", O_RDONLY) = 4
> read(4, "\0\0\0\0\f\222\20
On Fri, 3 May 2002, Tom Lane wrote:
> Stephen Amadei <[EMAIL PROTECTED]> writes:
> > I have been trying to run Postgres 7.2.1 in a chrooted environment, but
> > once I try to connect to the server with a "psql -l", it segfaults as it
> > tries to read from the data/global/1262.
>
> Urgh. Can you
Stephen Amadei <[EMAIL PROTECTED]> writes:
> I have been trying to run Postgres 7.2.1 in a chrooted environment, but
> once I try to connect to the server with a "psql -l", it segfaults as it
> tries to read from the data/global/1262.
Urgh. Can you provide a stack trace?
Hello.
I am new to the bugs list, so I hope this hasn't been covered before, but
I have a Slackware 8.0 system that is fairly up to date. Possibly to a
fault. Glibc is 2.2.5, gcc is 2.95.3, zlib is 1.1.4, kernel is 2.4.18
with the GRSecurity patch.
I have been trying to run Postgres 7.2.1 in
