From: Craig Ringer <ringerc@ringerc.id.au>
To: Venkat Balaji <venkat.balaji@verse.in>
Cc: pgsql-admin@postgresql.org
Subject: Re: Postgresql 9.0.1 installation error
Date: Wed, 10 Aug 2011 21:51:47 +0800
Message-ID: <4E428CF3.4070502@ringerc.id.au> (raw)
In-Reply-To: <CAFrxt0g42fx=GuE-NhcxqHSvFXwTOQNSPG3tE1QGqxrha-9sBQ@mail.gmail.com>
References: <CAFrxt0gxTJuqLtnXvvM=DEGQ+CJQMLt1UfdMJB4b8sEbTJO7uw@mail.gmail.com>
<4E40A0DD.3090400@ringerc.id.au>
<CAFrxt0gaYk1DFx3YThNj6Qu3DQ7HF6vnd3dvOhYXp9FLwDLueg@mail.gmail.com>
<4E42216A.4090109@ringerc.id.au>
<CAFrxt0g42fx=GuE-NhcxqHSvFXwTOQNSPG3tE1QGqxrha-9sBQ@mail.gmail.com>
On 10/08/2011 3:43 PM, Venkat Balaji wrote:
> libpq.so.5 => /opt/Postgres9.0.1/lib/libpq.so.5
OK, so it looks like it's runtime linking to the correct libpq, assuming
that the copy in /opt/Postgres9.0.1/ is the one for ... well .. 9.0.1 .
That was my first suspicion about what might be wrong, that it was being
runtime linked to a different libpq from a different build.
> Program received signal SIGSEGV, Segmentation fault.
> 0x00002aaaaaac3b8c in resetPQExpBuffer () from
> /opt/Postgres9.0.1/lib/libpq.so.5
> (gdb) bt\
> #0 0x00002aaaaaac3b8c in resetPQExpBuffer () from
> /opt/Postgres9.0.1/lib/libpq.so.5
> #1 0x00002aaaaaabd610 in pqGets_internal () from
> /opt/Postgres9.0.1/lib/libpq.so.5
> #2 0x0000000000658d70 in ?? ()
> #3 0x0000000000658d70 in ?? ()
> #4 0x0000000000659188 in ?? ()
> #5 0x0000000000000000 in ?? ()
While I'm no expert in the interpretation of wonky stack traces, I
strongly suspect you have a corrupt stack here. Those addresses don't
look right, and frame 5 is flat-out impossible AFAIK.
It's possible that the lack of debug symbols for other libraries and/or
the fact that you didn't rebuild with --enable-debug is the cause, but I
doubt it.
The trouble with stack corruption is finding the culprit. It's likely to
be something specific to your system, like a custom-built library you
installed in /usr/local that's being used for headers (includes) but not
for the library, or where the library in /usr/local is being used for
compile-time linking then a copy in /usr/lib is being used for runtime
linking. Stuff like that is often the cause... but it can also be a
genuine bug in libpq, psql, or one of the libraries that's only being
triggered under some circumstance particular to your system or build.
The first thing to do is see if you can make this bug happen on another
system that's configured as close to your current one as possible. If
you can't, figure out what's different about them. If you can still
reproduce it on a clean RHEL system, send the configure command,
installed package list and any other information required to reproduce
the bug to this mailing list.
Most likely you'll find that you can't reproduce it on a clean RHEL
system and will find something like a dodgy old copy of a library
somewhere, an installer that's overwritten a library in /usr/lib64 with
its own incompatible version, or something fun like that.
Unfortunately this kind of thing can be very hard to debug remotely. It
*might* help if you upload your config.log from your compile somewhere
and send a link to this mailing list (do not attach the file!), but it
might not land up telling me anything. Similarly, rebuilding Pg with
--enable-debug, running "make install" and re-testing might get a better
backtrace - or might be similarly useless.
--
Craig Ringer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: ringerc@ringerc.id.au, venkat.balaji@verse.in
Subject: Re: Postgresql 9.0.1 installation error
In-Reply-To: <4E428CF3.4070502@ringerc.id.au>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox