crash on long_xact regress in windows EDB 64-bit

[robe]

I've been ignoring all these 64-bit EDB regress failures, but started to look at them closer. This one surprised me.

This fails on both the EB 9.2 64bit and EDB 9.3beta1 64-bit and crashes the server. I double if many people use this feature, but something to look at.

It usually fails on this line of long_xact.sql

POSTGIS="2.1.0beta2 r11441" GEOS="3.4.0dev-CAPI-1.8.0 r0" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10.0, released 2013/04/24" LIBXML="2.7.8" LIBJSON="UNKNOWN" TOPOLOGY RASTER PostgreSQL 9.3beta1, compiled by Visual C++ build 1600, 64-bit {{{ —line 20 for 9.3 UPDATE test_locks SET state = 'unauthorized' where id = 1; }}}

for 9.2 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" RASTER PostgreSQL 9.2.4, compiled by Visual C++ build 1600, 64-bit

-- line 53 
UPDATE test_locks SET state = 'unauthorized' where id = 2;

so evidentally some sort of memory corruption. Doesn't happen under mingw-w64 testing or any of the 32-bit tests last I checked.

error in logs:

ERROR:  UPDATE where "id" = '1' requires authorization 'auth1'
STATEMENT:  UPDATE test_locks SET state = 'unauthorized' where id = 1;
LOG:  server process (PID 3764) was terminated by exception 0xC0000409

This is testing on my windows 7 64-bit.

[robe]

gathering from the errors before it kicks the bucket, must be breaking in the check_authorization trigger in postgis/long_xact.c around line 158

 snprintf(errmsg, ERRMSGLEN, "%s where \"%s\" = '%s' requires authorization '%s'",
                  op, colname, pk_id, lockcode);
         errmsg[ERRMSGLEN-1] = '\0';

[robe]

Ah great this one still crashes on my windows 7 64-bit 9.2 install running postgis 2.1.0beta3

PostgreSQL 9.2.4, compiled by Visual C++ build 1600, 64-bit POSTGIS="2.1.0beta3dev r11540" GEOS="3.4.0dev-CAPI-1.8.0 r0" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10.0, released 2013/04/19" LIBXML="2.7.8" LIBJSON="UNKNOWN" RASTER

with my gcc 4.5.4 build using sjlj error handling (this mingw64 chain

​http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/sezero_4.5_20111101/ )

,but doesn't with my new and improved gcc 4.8.0 using seh error handling. this chain ( ​http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/gcc-4.8-release/ ) ( ​http://en.wikipedia.org/wiki/Structured_Exception_Handling#Structured_Exception_Handling )

More details of differences in this thread: ​http://stackoverflow.com/questions/15670169/what-is-difference-between-sjlj-vs-dwarf-vs-seh

Thanks Mark for the suggestion. I think this might be the solution I've been looking for. Now to go thru all the other error handler crashers to see if this fixes them and I'm not night dreaming and then do a full regression and crash testing against my edb 64-bit install.

[robe]

yap EDB 64-bit 9.2.4 now passing regress with flying colors using gcc 4.8.0. I'm confident 9.3 will too especially since compiling with gcc 4.8.0 on 9.2 and 9.3 fixed my plv8 issues as well.

[robe]

I'm not going to fix this for 9.2 and below. 9.3+ however which is compiled with gcc 4.8.0 doesn't exhibit this issue. So will require 9.3 to get the fix.