Re: Postgresql 9.0.1 installation error

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
>