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

Re: Postgresql 9.0.1 installation error

From: Venkat Balaji <venkat(dot)balaji(at)verse(dot)in>
To: Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Postgresql 9.0.1 installation error
Date: 2011-08-11 05:45:18
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
Thanks Craig for your detailed explanation !

I had rebuilt the PG 9.0.1 with --enable-debug option.

As of now, i had downloaded a fresh package and re-installed. Its perfectly
working fine for me.

I will further try to debug this issue. Will let you know what i find.


On Wed, Aug 10, 2011 at 7:21 PM, Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> wrote:

> On 10/08/2011 3:43 PM, Venkat Balaji wrote:
> => /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

In response to


pgsql-admin by date

Next:From: Sofer, YuvalDate: 2011-08-11 10:00:33
Subject: Postgres service starts and then stops immediatly
Previous:From: Craig RingerDate: 2011-08-11 00:07:35
Subject: Re: postgresql server crash on windows 7 when using plpython

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