#2995 closed defect (fixed)
invalid access to memory location
Reported by: | robe | Owned by: | robe |
---|---|---|---|
Priority: | high | Milestone: | PostGIS 2.1.7 |
Component: | postgis | Version: | 2.1.x |
Keywords: | windows 64 | Cc: | dbaston |
Description (last modified by )
This may be a duplicate of #2476 and could even be a windows 64 specific issue. I'm not tagging it as raster this time though cause I'm not sure its raster.
Leo has managed to trigger this error:
invalid access to memory location
To be a bit annoying. One is a nightly process he runs which he was able to get around the issue by changing the order of the steps in his process. The only thing odd about his process is his unorthodox use of PostGIS (converting times to geometries so he could use geometry intersection and aggregate functions).
The other was just geocoding some data.
Neither invoived using any raster functions. I haven't quite pinpointed what could be the issue, but he's managed to trigger the problem on two separate Windows 64-bit boxes (one running Windows 2012 R2 and another Windows 2008 R2)
But same version of PostgreSQL / PostGIS:
POSTGIS="2.1.3 r12547" GEOS="3.4.2-CAPI-1.8.2 r3924" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10.0, released 2013/04/24" LIBXML="2.7.8" LIBJSON="UNKNOWN" RASTER PostgreSQL 9.3.5, compiled by Visual C++ build 1600, 64-bit
Change History (20)
comment:1 by , 10 years ago
Owner: | changed from | to
---|
comment:2 by , 10 years ago
Milestone: | PostGIS 2.1.5 → PostGIS 2.1.6 |
---|
comment:3 by , 10 years ago
comment:4 by , 10 years ago
Description: | modified (diff) |
---|
comment:5 by , 10 years ago
Cc: | added |
---|
comment:6 by , 10 years ago
I had what was seemed to be reliable case of this issue (repeatable after server restarts), but a few weeks later I am no longer able to replicate. I would still have an opportunity this Saturday to swap out an updated binary, if the buildchain is still thought to be a possible cause, but I don't think I will be able to confirm an immediate effect.
"PostgreSQL 9.2.2, compiled by Visual C++ build 1600, 64-bit POSTGIS="2.0.3 r11132" GEOS="3.3.8-CAPI-1.7.8" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.9.2, released 2012/10/08" LIBXML="2.7.8" LIBJSON="UNKNOWN" TOPOLOGY RASTER"
follow-up: 8 comment:7 by , 10 years ago
Okay I've started to build out the 9.2 on the newer gcc 4.8.1, I should soon and will post link here once its done building.
Did you want to go with 2.0 or 2.1? I guess I can build both.
comment:8 by , 10 years ago
I can go either way on 2.0 vs 2.1...if one would be more valuable than the other in tracking this down, let me know and I can use that.
comment:9 by , 10 years ago
Hmm that's a good question. I would say I care more about 2.1 than 2.0, but since you are at 2.0, it might be easier to compare.
Here is the link to 2.1 for 9.2 64 bit. I'm still fussing with the 2.0 (I had built that with older json and 2.0 doesn't work with newer json so have to patch that up before I have 2.0 ready).
http://winnie.postgis.net/download/windows/pg92/buildbot/postgis-pg92-binaries-2.1.5w64gcc48.zip
Anyway hopefully I didn't miss any dependencies (Note that replacing the *postgis*dll isn't sufficient since those rely on newer libraries included)
comment:10 by , 10 years ago
I built 2.0.6 as well. Something not setup right on the regression, so I wasn't able to regress to confirm its okay. I think its my EDB regression instance that is missing something rather than the build. Anyway if you want to give this one a try first before upgrading to 2.1. Eventually you'll want to go to 2.1.. Again all files are new so have to use full set of files here.
http://winnie.postgis.net/download/windows/pg92/buildbot/postgis-pg92-binaries-2.0.6w64gcc48.zip
comment:11 by , 10 years ago
Swapped out the files on my laptop before the production server (same config). Getting an error that
ERROR: could not load library "C:/Program Files/PostgreSQL/9.2/lib/postgis-2.1.dll": The specified procedure could not be found. SQL state: 58P01 Context: SQL statement "SELECT postgis_lib_version()" PL/pgSQL function postgis_full_version() line 19 at SQL statement
comment:12 by , 10 years ago
Okay I guess i'll have to whip out my 9.2 to check this out. I usually screw up on the libxml library.
comment:13 by , 10 years ago
As discussed in IRC the issue seems to be 9.2.9 they some how slipped HeapTupleHeaderGetDatum in 9.2.9 and since I had to rebuild my chain on newer ming, I went with the latest 9.2.9 (which happens to be incompatible with 9.2.8). Upgrading my desktop install from 9.2.8 to 9.2.9 made it work with the new binaries I built.
This is really something that shouldn't have happened in a micro, so might be something worthwhile bringing up to PostgreSQL folks if they are unaware of the issue.
comment:14 by , 10 years ago
comment:15 by , 10 years ago
Milestone: | PostGIS 2.1.6 → PostGIS 2.1.7 |
---|
comment:16 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I can't replicate this anymore since I upgraded my 64-bit chain to gcc 4.8.1 and haven't heard back from dbaston so assume he's okay too.
comment:17 by , 7 years ago
Not sure if I should open a new ticket but today I run into the same issue.
I have a database running for months now without any problem. I use it on a daily basis and yesterday everything was fine. Today I get this error when I select a table with a geometry column: ERROR: could not load library "D:/Program Files/PostgreSQL/9.3/lib/postgis-2.1.dll": Invalid access to memory location. The same error is shown when I run this command: SELECT postgis_lib_version()
I run Win10 Creator edition 64-Bit.
Any help is much appreciated since I'm really stuck now.
comment:18 by , 7 years ago
Have you tried restarting your computer? What exact version of PostGIS 2.1 are you running?
Any reason you can't upgrade to 2.2 or 2.3? http://winnie.postgis.net/download/windows/pg93/buildbot/
2.1 is pretty ancient at this point.
comment:19 by , 7 years ago
Of course I've restarted my laptop several times. I also tried manually restarting the PostgreSQL service. We're running PostgreSQL on AWS servers and those are 9.3 with PostGIS 2.1. And we have no need to upgrade since it always worked. Just this morning it got broken and only on my local instance.
The next upgrade on AWS is 9.5, perhaps we need to do an upgrade, but then we also need to upgrade to pgAdmin v4 and colleagues are already using it and it is a huge step back coming from pgAdminIII. But that is for a different thread ;)
I still don't understand why it is not working since this morning. I'll first try to upgrade to PostGIS v2.3
comment:20 by , 7 years ago
well PostgreSQL 9.5 still ships with pgAdmin III. pgAdmin 4 gets replaced at 9.6 for windows as I recall.
Yah no clue what could be different - you didn't install any other new software since else that may be conflicting or window 10 security updates. Those may have upgraded libraries incompatible with the 2.1 ones. 2.3 I use a newer chain so should be less likely to be an issue with newer software.
I think upgrading my build chain to gcc 4.8.3 might have fixed the issue. I shipped PostgreSQL 9.3 and 9.4 (PostGIS 2.1.5 with newer gcc build) and the job in question haven't been failing since we upgraded.
Leaving it open until further investigation.