Opened 7 years ago

Closed 5 years ago

Last modified 2 years ago

#1999 closed defect (duplicate)

Crash on LINESTRING with one point

Reported by: realityexists Owned by: pramsey
Priority: medium Milestone: PostGIS Fund Me
Component: postgis Version: trunk
Keywords: Cc:

Description

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

Change History (14)

comment:1 Changed 7 years ago by pramsey

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

comment:2 Changed 7 years ago by 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

comment:3 Changed 7 years ago by pramsey

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

comment:4 Changed 7 years ago by 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?

comment:5 Changed 7 years ago by 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.

comment:6 Changed 7 years ago by 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

comment:7 Changed 7 years ago by 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).

comment:8 Changed 7 years ago by 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.

comment:9 Changed 7 years ago by 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.

comment:10 Changed 7 years ago by 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)

comment:11 Changed 6 years ago by robe

Milestone: PostGIS 2.1.0PostGIS Future

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).

comment:12 Changed 6 years ago by 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

comment:13 Changed 5 years ago by robe

Resolution: duplicate
Status: newclosed

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

comment:14 Changed 2 years ago by robe

Milestone: PostGIS FuturePostGIS Fund Me

Milestone renamed

Note: See TracTickets for help on using tickets.