Crasher on ST_AsLatLonText on mingw64 (when used in VC EDB)

[robe]

So took my new postgis 64-bit windows for a spin and since I don't have make check working yet. Ran it thru my garden tests. It seems to consistently crash when it tries to log the output of an invalid ST_AsLonLat. It got thru the postgis 1.5 tests still standing though.

 SELECT query_to_xml('SELECT ST_AsLatLonText(foo1.the_geom, ''monkey'') As result FROM ((SELECT ST_SetSRID(ST_Point(i,j),4326) As the_geom FROM (SELECT a*1.11111111 FROM generate_series(-10,50,2) As a) As i(i) CROSS JOIN generate_series(40,70, 5) j ORDER BY i,j )) As foo1 LIMIT 3;', false,false, '');

After I restart it, I have to run this test about 4 times before it kills the server again. Haven't tried it on my mingw32 builds recently.

I also can't make it crash unless I combine it with query_to_xml which is what I use to log the results.

[robe]

forgot to say this is testing the build on EnterpriseDB 64bit 9.1 \using mingw64 compiled binaries.

[robe]

Okay was wrong this doesn't need query_to_xml to crash. However I can't get ti to crash under mymingw64 compiled postgresql. It only does it on my windows 2003 64-bit 9.1 EDB version and only if you give it an invalid format.

So this works:

SELECT ST_AsLatLonText(the_geom, 'D°M''S.SSS"C') As result, ST_AsText(the_geom) FROM ((SELECT ST_SetSRID(ST_Point(i,j),4326) As the_geom FROM (SELECT a*1.11111111 FROM generate_series(-10,50,2) As a) As i(i) CROSS JOIN generate_series(40,70, 5) j ORDER BY i,j )) As foo1 LIMIT 3;

This crashes the service wit EDB compiled version - but have to run it 3 times to force a crash and sometimes it refuses to crash after a restart though in my garden tests (presumably because I have 20 like calls, it manages to consistently kick)

SELECT ST_AsLatLonText(foo1.the_geom, 'monkey') As result FROM ((SELECT ST_SetSRID(ST_Point(i,j),4326) As the_geom FROM (SELECT a*1.11111111 FROM generate_series(-10,50,2) As a) As i(i) CROSS JOIN generate_series(40,70, 5) j ORDER BY i,j )) As foo1 LIMIT 3;

[strk]

Please try with r9435

[robe]

You sure that's the right revision. That one poitns to the one that pramsey committed which is broken.

[strk]

@robe I was assuming the commit was fixing the stringbuffer issue and that the ST_AsLatLonText is suffering from the exact same issue. Could as well be unrelated.

[robe]

I think it might be unrelated because sometimes it crashes and sometimes it doesn't and it only crashes when ST_AsLatLonText throws an error.

[strk]

What's the error it throws ?

[strk]

Nevermind, seen it, I'm on it.

[strk]

could you please test r9490

[robe]

Haven't retested yet but probably not worthwhile holding up a release for.

[robe]

Sadly its still crashing, but not sure its crashing in the same place. As far as I can tell, it seems to happen more or less guaranteed after a null that has no args after a run of null.

So for example the garden tester does 30 ST_AsLonLat tests (without format args) before it crashes. The tests that come right before the crasher that pass are all NULL tests. try this sequence

SELECT ST_AsLatLonText(foo1.the_geom) As result FROM ((SELECT CAST(Null As geometry) As the_geom)) As foo1 LIMIT 3;

SELECT ST_AsLatLonText(foo1.the_geom) As result FROM ((SELECT CAST(Null As geometry) As the_geom FROM generate_series(1,4) As foo)) As foo1 LIMIT 3;

SELECT ST_AsLatLonText(foo1.the_geom, 'monkey') As result FROM ((SELECT ST_SetSRID(ST_Point(i,j),4326) As the_geom FROM (SELECT a*1.11111111 FROM generate_series(-10,50,2) As a) As i(i) CROSS JOIN generate_series(40,70, 5) j ORDER BY i,j )) As foo1 LIMIT 3;

The last one crashes, but I can run it stand alone 10 - 20 times as long as I don't precede it by those other 2 it seems.

[robe]

Still crashes as of r11217, but I don't use this function so don't care don't care.

[strk]

wait wait, crashers are blockers, can't stand crashers. Better to disable the functionality as a whole than let any database user bring down a whole cluster.

It's even to be fixed in 2.0.x if exposed in that version (is it?)

[robe]

Well I'm guessing its something windows VC++ doesn't like about the error handling because it only happens if I pass in bogus data that would otherwise trigger an error.

Works great if I don't pass in ill-prepared string

[strk]

I cant get no valgrind reported error with your test. Crystal clear. Only ERROR: Bad format, degrees (DD.DDD) must be included. And the postgresql always present write(buf) to uninitialize bytes at startup. This is with postgresql 9.2.1, on a 64bit host -- what version are you running ?

[robe]

-- crashes --
POSTGIS="2.1.0SVN r11294" 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" (core procs from "2.1.0SVN r11230" need upgrade) RASTER (raster procs from "2.1.0SVN r11230" need upgrade);PostgreSQL 9.2.2, compiled by Visual C++ build 1600, 64-bit

-- gives this notice in postgres logs --
LOG:  server process (PID 3784) was terminated by exception 0xC0000409
DETAIL:  Failed process was running: 
	SELECT ST_AsLatLonText(foo1.the_geom, 'monkey') As result FROM ((SELECT ST_SetSRID(ST_Point(i,j),4326) As the_geom FROM (SELECT a*1.11111111 FROM generate_series(-10,50,2) As a) As i(i) CROSS JOIN generate_series(40,70, 5) j ORDER BY i,j )) As foo1 LIMIT 3;
	
	
HINT:  See C include file "ntstatus.h" for a description of the hexadecimal value.
LOG:  terminating any other active server processes
WARNING:  terminating connection because of crash of another server process

-- just throws error --
POSTGIS="2.1.0SVN r11294" 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.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


ERROR:  Bad format, degrees (DD.DDD) must be included.

It doesn't seem to happen on my mingw64 postgresql compiled.

[strk]

So it's really a VC++ thing. Shouldn't be assigned to me...

[robe]

something else fishy about this and just for VS

If I call this:

SELECT (ST_AsLatLonText('0101000020E6100000F771D98DE33826C00000000000004440'::geometry, 'D°M''S.SSS"C'));

I get back this

40°0'0.000"N 11°6'40.000"W

However:

SELECT (ST_AsLatLonText('0101000020E6100000F771D98DE33826C00000000000004440'::geometry));

Gives me nothing.

If I run on my mingw64 compiled postgres I get back

SELECT (ST_AsLatLonText('0101000020E6100000F771D98DE33826C00000000000004440'::geometry));
40°0'0.000"N 11°6'40.000"W

anyway I'm going to close this out as won't fix cause I don't use this function and don't care to waste time debugging it.