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:
> 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
>> (gdb) bt\
>> #0 0x00002aaaaaac3b8c in resetPQExpBuffer () from
>> #1 0x00002aaaaaabd610 in pqGets_internal () from
>> #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
> 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
> 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, Yuval||Date: 2011-08-11 10:00:33|
|Subject: Postgres service starts and then stops immediatly |
|Previous:||From: Craig Ringer||Date: 2011-08-11 00:07:35|
|Subject: Re: postgresql server crash on windows 7 when using plpython|