[postgis-devel] Windows 64-bit error handling issues Good and Bad News

[Paragon Corporation]

Sorry for the length of this message but just wanted to get people's
thoughts on this matter. As some may know I've been battling
With issues that only appear running postgis in 64-bit mode under PostgreSQL
EDB installers (they don't show urnning under pure mingw64)
These issue are isolated to how windows 64-bit handles errors and the
pattern is an erorr that requires a callback to another function seems to
often fail with the code just pretending like the error was never raised.
Issue described
http://stackoverflow.com/questions/15670169/what-is-difference-between-sjlj-
vs-dwarf-vs-seh and
http://en.wikipedia.org/wiki/Structured_Exception_Handling#Structured_Except
ion_Handling

Needless to say my newbie read SHE hadnling for 64-bit windows is preferred,
but structured error handling is not supported in GCC
Prior to 4.8.0 release.




1) The VERY good news is using Mingw64 GCC 4.8.0 that has structured error
handling (SEH) as Mark Cave-ayland suggested 

- (I think what VC++ 2010 and above use windows SEH for 64-bit error
handling)
I was able to get PostGIS 2.1.0 to regress cleanly with EDB VC++ builds
provided PostgreSQL 9.2.4 EDB 64-bit

(still need to test 9.3 chain)
Just for reference the regress failures were all triggered by when we
trigger an error and its only errors that are deep in.
Basically a function in postgis calls another function that is the one
triggering the error and the call back 

http://trac.osgeo.org/postgis/ticket/2338

http://trac.osgeo.org/postgis/ticket/2339


The bad news

1) My binaries are incompatible with the old PostGIS 2.0 (because of geos
and gdal that both  rely on C++ plumbing) which means I would need to
release a 2.0 at the same time as 2.1 for those who happened to have both
2.0 and 2.1 installed. Given 2.0 has same error handling issues -- its not a
bad idea

2) The other bad news -- not quite as bad, building PostgreSQL under mingw64
(both 32-bit and 64-bit) 4.8.0 gcc has a nasty little problem that the
libpq.dll generated  errors out when you launch psql

 could not connect to server: Operation would block (0x00002733/10035)
   Is the server running on host "localhost" (::1) and accepting

though only seems to affect psql. But causes the make check in building
postgresql to fail.

This is a known issue that many have complained about 
http://www.postgresql.org/message-id/E1UcLPd-0000L4-TI@wrigleys.postgresql.o
rg

and someone has even provided a patch for even 

http://www.postgresql.org/message-id/50F9D003.6000805@cybertec.at


I was able to get around this by swapping out the libpq with my 4.5.4
compiled psql (and I think even using edb one worked)
So not a major showstopper.  Just puzzling.  Only difference I can see is
the 4.8.0 compile psql has an extra dependency on user32.dll that the 4.5.4
and edb ones don't and given it affects the 32-bit as well (which doesn't
use seh), its not seh related and possibly because of this dependency.



So given that I haven't gotten a chance to really stress test this in the
field and I think most of the serious error handling issues we've added some
sand to so people don't slip, I'm tempted to

1) Build these binaries for 2.0, 2.1 chain -- but only offer them as
binaries for people who are running into the issue or would like
To test them out

2) When 2.2 rolls along - standardize on GCC 4.8.0  for windows build (both
32 and 64-bit branches) ( and I'll be experimenting with Mat's Cmake build
path as well now that I'm already successfully building GEOS,pgrouting with
cmake and partially successful with sfcgal and if brave enough might even
pull out VC 2012 express to see how well psotgis can really be built and
tested using cmake).

3) Another thought -- since 9.3 is not out, could just build these with
4.8.0 gcc (never with 4.5.4) but that complicates my buildbot machinery
quite a bit since I would need to run 9.3 on a separate mingw build chain
and rebuild all the dependencies under this mingw.  Doable but need much
config.

Anyone have an opinion on direction.

Thanks,
Regina
http://www.postgis.us
http://postgis.net