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-16 05:05:11
Message-ID: CAFrxt0i1c3Maou+OoAxqOu_TaiGhSnGG6QBbBbiSNDtUSdU2FA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Hi,

This issue is resolved.

Root Cause -

1. libpq library compilation problem
2. make file had the old configurations of previously performed
installations

Solution 1 -

"make clean" must be fired after "./configure" command and before "make
install" command.

Other work around ( possibly ) -

Using the copy of the same library file (which is corrupted) from another pg
installer bin directory can be used
Conditions - the pg must be installed with the same configure options and
obviously the version must be same.

This issue has been re-produced and tested.

Thanks
Nag

On Thu, Aug 11, 2011 at 11:15 AM, Venkat Balaji <venkat(dot)balaji(at)verse(dot)in>wrote:

> 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.
>
> Thanks
> Nag
>
>
> 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:
>>
>> 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
>>
>
>

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Scott Marlowe 2011-08-16 05:05:13 Re: Using Postgresql as application server
Previous Message Darren Duncan 2011-08-16 04:04:29 Re: Using Postgresql as application server