#2631 closed defect (duplicate)
Crash on Windows x64 reading geometry from invalid string
Reported by: | realityexists | Owned by: | robe |
---|---|---|---|
Priority: | high | Milestone: | PostGIS 2.1.2 |
Component: | postgis | Version: | 2.1.x |
Keywords: | Cc: |
Description
Run this a few times:
SELECT * FROM ( WITH test AS ( SELECT ST_MakeLine('0 0'::geometry, '0 0'::geometry) AS test_line ) SELECT test_line FROM test) sub
The first couple of times it returns an error, as expected ("Invalid hex string, length (3) has to be a multiple of two!"). The third time Postgres crashes with exception 0xC0000409!
PostgreSQL 9.2.6, compiled by Visual C++ build 1600, 64-bit POSTGIS="2.1.1 r12113" GEOS="3.4.2-CAPI-1.8.2 r0" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10.0, released 2013/04/24" LIBXML="2.7.8" LIBJSON="UNKNOWN" RASTER
Running on Windows 7 x64 SP1. I couldn't repro this on 32-bit Linux.
Change History (4)
comment:1 by , 11 years ago
Owner: | changed from | to
---|
comment:2 by , 11 years ago
comment:3 by , 11 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
realityexists - I think this is the issue with error handling I was using.
Try with 9.3 windows 7 64-bit: works on my windows 7 9.3 64-bit 2.1.2dev fine.
The issue I think is with the way errors were being handled. For 9.2 64-bit windows I compiled with gcc 4.5 which only had long jump handling. Unfortunately I ran into some situations like this where the errors were not handled properly. I think some were the ones you reported in fact.
For 9.3 and moving forward for 64-bit windows, I've been using gcc 4.8 with SEH (structure error handling), which doesn't seem to have this issue. long jump works fine for 32-bit so 32-bit windows never exhibited this issue (in fact because of patent issue seh is not available for windows 32-bit anyway) but I do compile 9.3 32-bit with gcc 4.8 also.
Short answer -- just upgrade to 9.3 for windows and the issue should go away. I've been debating recompiling 9.2 postgis with 4.8 but there weren't enough people complaining for me to warrant the risk of causing more damage (since if a person is running both PostGIS 2.0 and 2.1 under 9.2 -- an upgrade of one would break the other since the gcc 4.5 and 4.8 chains are not compatible). I also wasn't sure if I would run into issues with the 4.8. So far 4.8 has been really good, so I may just bite the bullet and redo 9.2 or at least offer gcc48 compiled 9.2 PostGIS for those who really want it.