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.bal...@verse.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 <ring...@ringerc.id.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 >> > >
