in_gml crashing and many regrss tests failing on mingw

[robe]

Now that I can regress again testing the alpha4, the ST_GeomFromKML, ST_GeomFromGML are crashing. This could be changes in my configuration.

Pierre -- getting any crashing and failures on the in_gml, in_kml.

I'm getting a lot of failures, but thoase coudl be the rsult of the database server restarting while the next set of tests are running.

My make check looks like this:

 PostgreSQL 9.1.2, compiled by Visual C++ build 1500, 32-bit
 Postgis 2.0.0alpha4 - 2012-02-12 03:24:28
   GEOS: 3.3.3dev-CAPI-1.7.3
   PROJ: Rel. 4.6.1, 21 August 2008

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 ............... ok 
 loader/MultiToSinglePoint ......... ok 
 loader/ReprojectPts ........ ok 
 loader/ReprojectPtsGeog ........ ok 
 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 
 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_2176/test_51_diff)
 in_kml .. failed (diff expected obtained: /tmp/pgis_reg_2176/test_52_diff)
 iscollection .. failed (diff expected obtained: /tmp/pgis_reg_2176/test_53_diff)
 regress_ogc .. failed (diff expected obtained: /tmp/pgis_reg_2176/test_54_diff)
 regress_ogc_cover .. failed (diff expected obtained: /tmp/pgis_reg_2176/test_55_diff)
 regress_ogc_prep .. failed (diff expected obtained: /tmp/pgis_reg_2176/test_56_diff)
 regress_bdpoly .. failed (diff expected obtained: /tmp/pgis_reg_2176/test_57_diff)
 regress_proj .. failed (diff expected obtained: /tmp/pgis_reg_2176/test_58_diff)
 regress_management .. failed (diff expected obtained: /tmp/pgis_reg_2176/test_59_diff)
 dump .. failed (diff expected obtained: /tmp/pgis_reg_2176/test_60_diff)
 dumppoints .. failed (diff expected obtained: /tmp/pgis_reg_2176/test_61_diff)
 wmsservers .. ok 
 wkt .. ok 
 wkb .. ok 
 tickets .. failed (diff expected obtained: /tmp/pgis_reg_2176/test_65_diff)
 typmod .. failed (diff expected obtained: /tmp/pgis_reg_2176/test_66_diff)
 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 
 uninstall .. ok (3855)

[robe]

regress failures - looks like probably mostly due to from gml kml failing

[robe]

Checked my database with alpha2 installed on it and that one is fine.

This command crashes my alpha4. I have to dig out my alpha3 build to test.

SELECT ST_GeomFromGML('<gml:Point><gml:coordinates>1,1</gml:coordinates></gml:Point>');

[robe]

My alpha3 build also crashes. I'll have to check its not something different in how I'm compiling.

[robe]

Okay I recompiled my alpha2 using the same current script I am using to compile alpha4 and alpha2 resulting dll is fine in that the above test returns something.

So unless I am loosing my mind (which I can't discount), something changed between alpha2 and alpha3 to cause this issue.

Pierre -- you are running the same mingw version I am. Can you check and see if the above passes. I'm running on a windows 7 64-bit so that might make a difference.

[pracine]

In my case one of the CUnit test fails:

Suite: WKT In Suite

Test: test_wkt_in_point ... FAILED

1. cu_in_wkt.c:71 - CU_ASSERT_STRING_EQUAL(r,"POINT(inf 0)")

And many regress fail as well... Mostly the one you identified above.

[robe]

Interesting. All my cunits pass. Are you on windows 7 32-bit or 7 64-bit or some other windows?.

in_gml / in_kml I guess I'll have to hunt what changed between alpha2 and alpha3. Originally I thought it was something I was doing during the compile process (to revert back to issues I had in 1.5), but fact recompiling the alpha2 gives me a good buld and you have the same issue would seem to dispell that notion.

As far as regress_* and typmod tickets, I don't think those are true failures but result of the tests crashing on in_gml/in_kml and tickets and the postgres process trying to stand back up from a knockout punch.

Thanks Pierre :)

[pracine]

I'm on Windows 7 64-bit but SELECT version() gives:

"PostgreSQL 9.1.2 on i686-pc-mingw32, compiled by gcc.exe (GCC) 3.4.5 (mingw special), 32-bit"

and I'm using the old MinGW.

[robe]

That's what I'm using too. The cunit tests should be indifferent of postgresql version since they don't touch PostgresQL. The other tests the postgresql specific ones I test again the EnterpriseDB windows binaries (suualy the 9.1.2) so some of those may be different. Weird how our cunits don't agree. I'll have to double-check mine.

[pracine]

Could the fact that I did not compile json explain something?

[pramsey]

Stuff the deadly SQL through GDB and find the place where it segfaults...

http://trac.osgeo.org/postgis/wiki/DevWikiGettingABackTrace

[robe]

Okay gives this message

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 5080.0xf64]
0x0053d440 in postgres!gistgetadjusted ()

[pramsey]

Type 'bt' to get the whole trace.

[strk]

robe: can you run, from regress/ dir:

./run_test -v in_gml

[robe]

I'll have to setup my mingw compiled 9.1. I'm not getting much with bt presumably because I don't have debug symbols for the 9.1.2 windows build.

Just gives me:

#0  0x0057d440 in postgres!gistgetadjusted ()

Pierre -- can you do the same test on yours?

[pracine]

Pierre -- can you do the same test on yours?

I would have to recompile postgresql in debug mode (is it by default?) and this frighten me now that I have a stable environment. I should have a compile one and a development one but I don't... yesterday I just updated postgis and noting was compiling anymore. I had to recheckout the whole trunk.

[robe]

Okay I think I have isolated my issue down to commit r8945

[robe]

disregard. Not that one -- later on in chain.

[robe]

Okay I think I got it this time: r8963

I'll go back one version just to confirm -- but I tested up thru r8951 and all those were fine and the ones between r8951 and r8963 seem mostly like harmless topology changes. I tested r8963 and bam. I was also wrong it is just st_geomfromGML that is affected. kml failed because the geomfromgml test crashed my server.

[strk]

This is suspicious, in r9237:

+ printf("srsname %s\n",srsname);

I bet a NULL srsname kills windows.

We shouldn't be using printf in code anyway. Removed as of r9239, see how it goes.

[robe]

Good catch. works now. Thanks