Re: 8.2beta1 crash possibly in libpq - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: 8.2beta1 crash possibly in libpq
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCEA357B7@algol.sollentuna.se
Whole thread Raw
In response to Re: 8.2beta1 crash possibly in libpq  (Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>)
Responses Re: 8.2beta1 crash possibly in libpq  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: 8.2beta1 crash possibly in libpq  (Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>)
List pgsql-hackers
> > > AFAICT the backtrace and server log is indicating that the
> > > crash is happening somewhere in libpq. If someone can help me
> > > figure out how to load the libpq symbols into MingW's gdb
> > > then I can get a better backtrace if required as I can
> > > reproduce this 100% of the time. For reference, the source
> > > for the application in question can be found at
> > >
> http://svn.refractions.net/postgis/tags/1.1.4/loader/pgsql2shp.c.
> >
> > If you figure out how to make gdb actually work on mingw, let us
> know -
> > not many has ever managed to get it wokring, and I don't know of
> anybody
> > who can make it work repeatedly.
> >
> > That said, libpq builds with Visual C++. Could you try building
> your
> > pgsql2shp with Visual C++ as well, and then use the Visual C++
> debugger
> > (or windbg, really). They should give working backtraces.
> >
> > //Magnus
>
>
> Hi Magnus,
>
> Getting closer I think. I managed to compile a MSVC libpq but it
> agreed
> with the MingW backtrace in that it was jumping into the middle of
> nowhere :(

Oops. Sounds like a generic memory corruption then, overwriting the
return stack so the backtrace doesn't work.


> I think I may be getting closer though: I've just done a comparison
> build with PostgreSQL 8.1 and noticed that there is an error
> message is
> being emitted regarding PGntuples (which is where the crash is
> occuring):

> mca@MCAWINXP ~/postgis/pg81/postgis-1.1.4/loader
> $ make
> gcc -g -Wall -I.. -DUSE_ICONV -DUSE_VERSION=81   -c -o shpopen.o
> shpopen.c


A question based on that - are you using gettext? I know gettext, and
possibly iconv, breaks if gettext is compiled with one version of VC++
and the program using it a different version. If you are building with
it, try to disable it and see if that's where the problem is from.

<snip>

> C:/msys/1.0/home/mca/pg82/REL-8~1.2BE/lib/libpq.dll -o
> pgsql2shp.exe
> Info: resolving _PQntuples by linking to __imp__PQntuples (auto-
> import)
>
>
> I think the key part is this line: "Info: resolving _PQntuples by
> linking to __imp__PQntuples (auto-import)". Could it be that the
> linker
> cannot find a reference to PQntuples and hence is jumping into
> random
> code? I have verified that PQntuples does exist within libpq.dll
> using
> the Microsoft Dependency Walker though.

This is fairly normal, and it's just info - not even a warning. If it
couldn't find the refenrence, you'd get one of those "could not find
entrypoint in DLL" errorboxes when you tried to start the program. It
absolutely will not just pick a random memory and jump to. You could
possibly do that yourself if you were loading the DLL manually, but
since you're not doing that...

//Magnus



pgsql-hackers by date:

Previous
From: Mark Cave-Ayland
Date:
Subject: Re: 8.2beta1 crash possibly in libpq
Next
From: "Merlin Moncure"
Date:
Subject: Re: The improvement for psql of 8.2beta1 not