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
Re: 8.2beta1 crash possibly in libpq |
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: