totally non-sensical regress failure with empty tickets.sql

[robe]

This doesn't happen on winnie at all, but happens on my windows 7 9.2 32-bit

hey but yeh my geos version shows instead of 0.

PostgreSQL 9.2.1 on i686-w64-mingw32, compiled by i686-w64-mingw32-gcc.exe (GCC) 4.5.4 20111030 (prerelease) [svn/rev.180676 - mingw-w64/oz], 32-bit POSTGIS="2.1.0SVN r11228" GEOS="3.4.0dev-CAPI-1.8.0 r3793" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.9.2, released 2012/10/08" LIBXML="2.7.8" LIBJSON="UNKNOWN" RASTER

but:

SELECT '#2110.2', 'POINT EMPTY'::geometry = 'POINT EMPTY'::geometry;

?column? | ?column?
---------+----------
#2110.2  | f

I did blow out my postgis source because ti was acting funny and started from scratch

I'll test next on my 64-bit and then under EDB. boy do I hate empties.

[robe]

well my mingw64-w64 is not showing the same issue, but then again I have slightly different micros of everything.

PostgreSQL 9.2.2 on x86_64-w64-mingw32, compiled by x86_64-w64-mingw32-gcc.exe (
GCC) 4.5.4 20111030 (prerelease) [svn/rev.180676 - mingw-w64/oz], 64-bit
 - 2013-03-30 14:32:25
  GEOS: 3.4.0dev-CAPI-1.8.0 r0
  PROJ: Rel. 4.8.0, 6 March 2012

But I fear its one of those strange errors that only shows for a particlular micro of postgresql on windows 7 and windows 2008 but not windows 2003 64-bit.

[Bborie Park]

I'm too am seeing this error with 32-bit mingw on Windows 7. Debug time...

[robe]

Leaky abstraction :). I think part of the reason why windows is so hard to debug is that all the binaries work more or less from windows 2000 -> windows 2008, windows 2000 desktop, windows 7 (I still got to test Windows 2012 server and windows 8) and all permutations of 32-bit, 64-bit. Yet all these OS I am finding are quite different under the hood.

[robe]

okay this is spooky. Just tested again and it showed up right on my windows 9.2 edb install, but then I tried again just running a second time and it was WRONG. it literally went from "t" to "f" and once false just stayed at false.

I think there is a memory leak somewhere. Last time I saw this behavior was when address space was not being cleaned right and running in 32-bit mode on a 64-bit OS was especially sensitive to this sloppy cleanup.

select postgis_full_version() || ' ' || version();

POSTGIS="2.1.0SVN r11249" GEOS="3.4.0dev-CAPI-1.8.0 r0" 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.1, compiled by Visual C++ build 1600, 32-bit

SELECT '#2110.2', 'POINT EMPTY'::geometry = 'POINT EMPTY'::geometry;

[Bborie Park]

I think this might be a compound issue. In looking at the code for lwgeom_eq() in postgis/lwgeom_btree.c, it is failing on the second if/else evaluation around line #195. Both input geometries result in the variables empty1 and empty2 being TRUE.

The problem is that the second test compares the coordinates for the boxes, which are uninitialized (so says valgrind when running in Linux 64-bit)...

Adding some additional debug output...

POSTGIS_DEBUGF(3, "empty1, empty2 = %d, %d", empty1, empty2);
POSTGIS_DEBUGF(4, "%f ~ %f, %f ~ %f, %f ~ %f, %f ~ %f",
	box1.xmin, box2.xmin, box1.ymin, box2.ymin, box1.xmax, box2.xmax, box1.ymax, box2.ymax);

results in...

NOTICE:  [lwgeom_btree.c:lwgeom_eq:189] empty1, empty2 = 1, 1
NOTICE:  [lwgeom_btree.c:lwgeom_eq:191] 0.000000 ~ 0.000000, 0.000000 ~ 0.000000
, 0.000000 ~ 1.#INF00, 0.000000 ~ 0.000000
 ?column?
----------
 f
(1 row)

[Bborie Park]

Yep. Calling gbox_init() on the GBOX variables in lwgeom_eq() fixes it. Fixed in r11256. I have no regression failures now.

[robe]

Cool. Its the same issue on my 2.0 install. Can you back port since its clearly a bug or I can backport if you want me to.

[Bborie Park]

Fixed for 2.0 in r11258.