#1754 closed defect (fixed)
in_gml regress check crashes on vc++ 64 edb (only 9.3)
Reported by: | robe | Owned by: | robe |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 2.1.0 |
Component: | postgis | Version: | 2.0.x |
Keywords: | mingw64, windows 64bit, history | Cc: |
Description
I guess I had neglected to do make check against edb builds and was doing it on my compiled versions.
Sadly I'm seeing a lot of crashes here — though not sure if much can be done about it.
On 9.1.3 VC++ compiled (note mingw64 is more or less okay except for the rounding issues)
PostgreSQL 9.1.3, compiled by Visual C++ build 1500, 64-bit Postgis 2.0.0 - r9605 - 2012-04-04 15:31:29 GEOS: 3.3.3-CAPI-1.7.4 PROJ: Rel. 4.8.0, 6 March 2012 Running tests loader/Point ....................... ok loader/PointM ....................... ok loader/PointZ ....................... ok loader/MultiPoint ....................... ok loader/MultiPointM ....................... ok loader/MultiPointZ ....................... ok loader/Arc ....................... ok loader/ArcM ....................... ok loader/ArcZ ....................... ok loader/Polygon ....................... ok loader/PolygonM ....................... ok loader/PolygonZ ....................... ok loader/TSTPolygon ......... ok loader/TSIPolygon ......... ok loader/TSTIPolygon ......... ok loader/PointWithSchema ..... ok loader/NoTransPoint ......... ok loader/NotReallyMultiPoint .... failed (wkt test: diff expected obtained: /tmp/ pgis_reg/test_18_diff) loader/MultiToSinglePoint ... failed ( wkt test: running shp2pgsql output: /tmp /pgis_reg/loader.err) loader/ReprojectPts .... failed ( wkt test: running shp2pgsql output: /tmp/pgis _reg/loader.err) loader/ReprojectPtsGeog .... failed ( wkt test: running shp2pgsql output: /tmp/ pgis_reg/loader.err) loader/Latin1 .... ok binary .. ok regress .. ok regress_index .. ok regress_index_nulls .. ok lwgeom_regress .. ok regress_lrs .. ok removepoint .. ok setpoint .. ok simplify .. ok snaptogrid .. ok summary .. ok affine .. ok empty .. ok measures .. ok legacy .. ok long_xact .. ok ctors .. ok sql-mm-serialize .. ok sql-mm-circularstring .. ok sql-mm-compoundcurve .. ok sql-mm-curvepoly .. ok sql-mm-general .. ok sql-mm-multicurve .. ok sql-mm-multisurface .. ok polyhedralsurface .. ok polygonize .. ok postgis_type_name .. ok out_geometry .. ok out_geography .. ok in_gml .. failed (diff expected obtained: /tmp/pgis_reg/test_52_diff) in_kml .. failed (diff expected obtained: /tmp/pgis_reg/test_53_diff) iscollection .. failed (diff expected obtained: /tmp/pgis_reg/test_54_diff) regress_ogc .. failed (diff expected obtained: /tmp/pgis_reg/test_55_diff) regress_ogc_cover .. failed (diff expected obtained: /tmp/pgis_reg/test_56_diff ) regress_ogc_prep .. failed (diff expected obtained: /tmp/pgis_reg/test_57_diff) regress_bdpoly .. failed (diff expected obtained: /tmp/pgis_reg/test_58_diff) regress_proj .. failed (diff expected obtained: /tmp/pgis_reg/test_59_diff) regress_management .. failed (diff expected obtained: /tmp/pgis_reg/test_60_dif f) dump .. ok dumppoints .. ok wmsservers .. ok wkt .. ok wkb .. ok tickets .. ok typmod .. ok remove_repeated_points .. ok split .. ok relate .. ok bestsrid .. ok concave_hull .. ok hausdorff .. ok regress_buffer_params .. ok offsetcurve .. ok relatematch .. ok isvaliddetail .. ok sharedpaths .. ok snap .. ok node .. ok unaryunion .. ok clean .. ok relate_bnr .. ok in_geojson .. ok uninstall .. ok (3857) Run tests: 85 Failed: 13 make: *** [check] Error 13
The in_gml one is the result of a crash. I suspect a lot of the others that follow are server trying to stand back up from crahs. I vaguely remember having this issue with my 32-bit build before but can't recall if we changed something to fix the issue and it was a memory leak.
Raster looks good though comes thru with flying colors on both vc++ and mingw64 pg
Attachments (1)
Change History (11)
by , 13 years ago
Attachment: | pgis_reg_mingw64_447_edb913.zip added |
---|
comment:1 by , 13 years ago
comment:2 by , 13 years ago
Owner: | changed from | to
---|
comment:3 by , 13 years ago
Okay things look way better if I take the in_gml test out so it really is just in_gml failing. The others are harmless rounding issues (or the reporject failing only when in battery of tests) I see compiling against regular mingw64 compiled postgres.
PostgreSQL 9.1.3, compiled by Visual C++ build 1500, 64-bit Postgis 2.0.0 - r9605 - 2012-04-04 15:31:29 GEOS: 3.3.3-CAPI-1.7.4 PROJ: Rel. 4.8.0, 6 March 2012 Running tests loader/Point ....................... ok loader/PointM ....................... ok loader/PointZ ....................... ok loader/MultiPoint ....................... ok loader/MultiPointM ....................... ok loader/MultiPointZ ....................... ok loader/Arc ....................... ok loader/ArcM ....................... ok loader/ArcZ ....................... ok loader/Polygon ....................... ok loader/PolygonM ....................... ok loader/PolygonZ ....................... ok loader/TSTPolygon ......... ok loader/TSIPolygon ......... ok loader/TSTIPolygon ......... ok loader/PointWithSchema ..... ok loader/NoTransPoint ......... ok loader/NotReallyMultiPoint .... failed (wkt test: diff expected obtained: pgis_reg/test_18_diff) loader/MultiToSinglePoint ... failed ( wkt test: running shp2pgsql output: /pgis_reg/loader.err) loader/ReprojectPts .... failed ( wkt test: running shp2pgsql output: /tmp _reg/loader.err) loader/ReprojectPtsGeog .... failed ( wkt test: running shp2pgsql output: pgis_reg/loader.err) loader/Latin1 .... ok binary .. ok regress .. ok regress_index .. ok regress_index_nulls .. ok lwgeom_regress .. ok regress_lrs .. ok removepoint .. ok setpoint .. ok simplify .. ok snaptogrid .. ok summary .. ok affine .. ok empty .. ok measures .. ok legacy .. ok long_xact .. ok ctors .. ok sql-mm-serialize .. ok sql-mm-circularstring .. ok sql-mm-compoundcurve .. ok sql-mm-curvepoly .. ok sql-mm-general .. ok sql-mm-multicurve .. ok sql-mm-multisurface .. ok polyhedralsurface .. ok polygonize .. ok postgis_type_name .. ok out_geometry .. ok out_geography .. ok in_kml .. ok iscollection .. ok regress_ogc .. ok regress_ogc_cover .. ok regress_ogc_prep .. ok regress_bdpoly .. ok regress_proj .. ok regress_management .. ok dump .. ok dumppoints .. ok wmsservers .. ok wkt .. ok wkb .. ok tickets .. ok typmod .. ok remove_repeated_points .. ok split .. ok relate .. ok bestsrid .. ok concave_hull .. ok hausdorff .. ok regress_buffer_params .. ok offsetcurve .. ok relatematch .. ok isvaliddetail .. ok sharedpaths .. ok snap .. ok node .. ok unaryunion .. ok clean .. ok relate_bnr .. ok in_geojson .. ok uninstall .. ok (3857) Run tests: 84 Failed: 4 make: *** [check] Error 4
comment:4 by , 13 years ago
Summary: | Regress failures against edb windows 64-bit builds → in_gml regress check crashes on vc++ 64 edb |
---|
comment:5 by , 13 years ago
and running the file from pgadmin the in_gml script works fine. A heisenbug though interstingly it always crashes in that file when run under make check.
comment:6 by , 13 years ago
Milestone: | PostGIS 2.0.1 → PostGIS 2.0.2 |
---|
Since this only crashes during tests and not sure if it even crashes with the new perl since I haven't retested by VC++ compiled postgres, I think this can wait.
comment:10 by , 11 years ago
Keywords: | history added |
---|---|
Summary: | in_gml regress check crashes on vc++ 64 edb → in_gml regress check crashes on vc++ 64 edb (only 9.3) |
This is interesting. the 64-bit edb calls their xml lib libxml2-2.dll which is the same name I compile against. The 32-bit calls theirs libxml2.dll. No wonder I was so confused.
Think its an incompatibility with the libxml with how its throwing exceptions. Using the packaged libxml works okay for in out with some samples that I've done but I think its failing on the tests we have that throw exceptions.