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 >
