Crash on LINESTRING with one point

[realityexists]

Run the following a couple of times and PostgreSQL crashes:

CREATE OR REPLACE FUNCTION _dummy_func(lines geometry(LineString)[])
RETURNS geometry(LineString) AS
'BEGIN RETURN lines[1]; END'
LANGUAGE plpgsql IMMUTABLE;

SELECT ST_AsText(_dummy_func(ARRAY['LINESTRING(5 5)'])), ST_AsText(_dummy_func(ARRAY['LINESTRING(5 5)']));

The first time it returns "ERROR: geometry requires more points" as expected. The second time it crashes.

Windows 7 x64, PostgreSQL 9.1.4 x64

POSTGIS="2.1.0SVN r10237" GEOS="3.4.0dev-CAPI-1.8.0 r0" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.9.1, released 2012/05/15" LIBXML="2.7.8" LIBJSON="UNKNOWN" RASTER

[pramsey]

This still around? Not seeing it on OSX under 2.0 branch or trunk.

[realityexists]

Yes, this still happens on PostgreSQL 9.1.4 x64, but not on PostgreSQL 9.2.1 x64. PostGIS_Full_Version():

POSTGIS="2.1.0SVN r10648" GEOS="3.4.0dev-CAPI-1.8.0 r0" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.9.1, released 2012/05/15" LIBXML="2.7.8" LIBJSON="UNKNOWN" RASTER

[pramsey]

Yay, windows bug. Same versions but OSX, everything works fine. Starting to build up a backlog of these win64 bugs.

[robe]

pramsey,

Not convinced this is a windows 64-bit issue (or at least not only since it doesn't affect the 9.2.1x64). Like reality_exists I have confirmed it happens on my 9.1.4x64 EDB windows 2008 r2, but not my 9.2.1 x64 EDB windows 2008 r2. I don't have a 32-bit 9.1 readily handy. 9.2.1 x32 EDB is fine as well. Unfortunately don't have latest 9.1x32 compiled to test.

Which version of PostgreSQL are you running and 32/64?

[robe]

If it is a windows 64-bit issue, it might be a result of improvements they've made in mingw64 compile between 9.1 and 9.2

For example in 9.2 I can compile for both 32-bit and 64-bit under mingw64 chain, but 9.1 I can compile only the 64-bit chain.

[robe]

FWIW: I'm seeing 0xC0000409 in logs which corresponds to buffer over run. There have been a couple of reports in posgresql mailing list in the past 3 months (some 9.2 as well too though) or so for windows 64-bit. Here is another specific to PostGIS. ​http://archives.postgresql.org/pgsql-hackers/2012-11/msg00079.php

The others are unclear if PostGIS is involved or not.

​http://www.postgresql.org/search/?m=1&q=was+terminated+by+exception+0xC0000409&l=&d=365&s=r

[pramsey]

So, why does this require a fancy function to unearth? Doesn't running

SELECT 'LINESTRING(0 0)'::geometry;

a couple times do it? Can you capture the crash in gdb and get a stack-trace? That would be a first hint of where things go off the rails (though it's pretty clearly a memory corruption problem, so it could be really hard to figure out).

[realityexists]

Not sure how I could get a stack trace on Windows, even if I had gdb installed, given that there are no PDB files in the Windows PostGIS build. I don't have x64 Linux available, only x86 with PostgreSQL 9.2 and it doesn't happen there.

Yes, it does require the fancy function to repro - simply running the SELECT returns the expected error every time, no crashes. One slightly strange thing I've noticed is that there is sometimes an extra newline after the hint, ie.

ERROR:  geometry requires more points
LINE 1: SELECT 'LINESTRING(0 0)'::geometry;
               ^
HINT:  "LINESTRING(0 0)" <-- parse error at position 16 within geometry
<phantom blank line>

Probably unrelated, but that extra new line shows up maybe 1-2 times out of 10 attempts. That's running from pgAdmin, so possibly a pgAdmin issue.

[robe]

I'll try to capture in gdb later tomorrow and also see if it just happens in EDB or happens under mingw64 compiled postgresql as well.

I've run into a lot of cases that work fine in ming environment and crash in EDB (for the 64-bit) and was meaning to enable testing on EDB as well but then when manually retest on EDB work fine. I haven't bothered setting up EDB testing because Winnie's EDB screaming would drive pramsey insane.

[robe]

confirmed this doesn't happen on windows 32-bit 9.1. so only happens on

9.2x64 windows edb fine
9.2x32 windows edb fine
9.1x32 windows edb fine (just tested under windows 7-64bit)
9.1x64 windows edb (bad)

I still have to check 9.0x64 (and the various mings)

[robe]

This requires a retest — given its seems to only happen under windows 9.1x64 windows running on windows 7 or windows 2008 (can't replicate on 64-bit windows 2003) and only under a specific circumstance (and probably also has to do with micro version), I'm tempted to punt this till later. I'm going to do an intensive garden test before release (something I've feared doing for a while, and it will probably come up with a whole bunch of more scarier crashers).

[robe]

Thought I had a note on this ticket about this (thought might have been on ST_AsText which has a similar issue but more user facing focused). I think the workaround was to get rid of the IMMUTABLE

[robe]

error handling issue solved in #2339 Issue also reported in #2631

[robe]

Milestone renamed