ST_LineCrossingDirection Server Crash (Segfault)

[batzee]

Table definition:

   Spalte    |          Typ           |                           Attribute                            
-------------+------------------------+----------------------------------------------------------------
 timeline_id | integer                | not null default nextval('timeline_timeline_id_seq'::regclass)
 name        | character varying(64)  | not null
 shortname   | character varying(16)  | not null
 theline     | geometry               | 
 visible     | boolean                | not null default false
 country_id  | integer                | 
 comment     | character varying(256) | 
Indexe:
    »timeline_pkey« PRIMARY KEY, btree (timeline_id)
    »unq_name« UNIQUE, btree (name)
    »unq_shortname« UNIQUE, btree (shortname)
Check-Constraints:
    »enforce_dims_theline« CHECK (ndims(theline) = 2)
    »enforce_geotype_theline« CHECK (geometrytype(theline) = 'LINESTRING'::text OR theline IS NULL)
    »enforce_srid_theline« CHECK (srid(theline) = (-1))
Fremdschlüssel-Constraints:
    »timeline_country_id_fkey« FOREIGN KEY (country_id) REFERENCES country(country_id)

Query:

select name,st_linecrossingdirection(theline, GeomFromText('LINESTRING(2 53.54,20 53.54)')) from mytable;

Output in PSQL client:

server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.
Lost connection to server. Trying to Reset: Failed.
!> 

Output in server logfile (sorry for German..):

2009-08-18 18:30:58 CEST ANWEISUNG:  select * from timeline where st_linecrossingdirection(theline, GeomFromText('LINESTRING(8 53.54,11 53.54)'));
2009-08-18 18:31:42 CEST LOG:  Serverprozess (PID 16539) wurde von Signal 11 beendet: Segmentation fault
2009-08-18 18:31:42 CEST LOG:  aktive Serverprozesse werden abgebrochen
2009-08-18 18:31:42 CEST FATAL:  das Datenbanksystem ist im Wiederherstellungsmodus
2009-08-18 18:31:42 CEST LOG:  alle Serverprozesse beendet; initialisiere neu

[pramsey]

Can you do a binary search and find the geometry that causes the crash? Use limit and offset to search 1/2, 1/4, 1/8 of the data table until you find the one record that is causing the problem...

select name,
st_linecrossingdirection(theline, GeomFromText('LINESTRING(2 53.54,20 53.54)')) 
from mytable limit 500 offset 500;

[batzee]

It seems the crash is not directly related to a geometry, or at least I cannot find it. The query crashes with every offset >74.

Table size is 125.

It even crashes with offset 100000.

[pramsey]

Can you just dump and attach the table then? I need to create the crash on my own machine in order to debug it.

[robe]

Paul,

I can make my server crash with this

SELECT sum(ST_LineCrossingDirection(a.the_geom, b.the_geom)) FROM ((SELECT ST_MakeLine(ST_Point(i,j),ST_Point(j,i)) As the_geom

FROM generate_series(-10,100,5) As i

CROSS JOIN generate_series(5,70, 4) As j WHERE NOT(i = j) ORDER BY i, i*j)) As a CROSS JOIN

((SELECT ST_MakeLine(ARRAY[ST_Point(i,j),ST_Point(j,i), ST_Point(k,i), ST_Point(j,k)]) As the_geom

FROM generate_series(-10,10000,1500) As i

CROSS JOIN generate_series(5,800, 7) As j CROSS JOIN generate_series(0,800, 200) As k WHERE NOT(i = j) AND NOT (j = k) AND NOT (k = i) ORDER BY i, i*j)) As b

WHERE ST_LineCrossingDirection(a.the_geom,ST_GeomFromText('LINESTRING(8 53.54,11 53.54)')) = 1

I could probably have come up with a simpler statement :). It appears to be the use in where condition. Without that it works fine.

[robe]

On closer inspection. I think its how we are freeing constant geometries that is the problem. Only seems to happen if I introduce a constant.

For example this crashes too.

SELECT sum(ST_LineCrossingDirection(a.the_geom, ST_GeomFromText('LINESTRING(1 2,3 4)'))) FROM ((SELECT ST_MakeLine(ST_Point(i,j),ST_Point(j,i)) As the_geom

FROM generate_series(-10,50,10) As i

CROSS JOIN generate_series(40,70, 15) As j WHERE NOT(i = j) ORDER BY i, i*j) ) As a

[batzee]

Replying to pramsey:

Can you just dump and attach the table then? I need to create the crash on my own machine in order to debug it.

I can send it to you as a PM. Attaching the data to a public forum is not possible, sorry. Pls let me know your e-mail address if you still need the dump. Mine is post at bastian minus voigt dot de

[nicklas]

I took a quick look at Reginas example. The crash only appears when there is more than one row. If I make a table like

create table c as 
SELECT ST_MakeLine(ST_Point(-10,40),ST_Point(40,-10)) As the_geom ;
insert into c 
SELECT ST_MakeLine(ST_Point(0,40),ST_Point(40,0)) As the_geom ;

then this crashes:

SELECT sum(ST_LineCrossingDirection(the_geom, ST_GeomFromText('LINESTRING(1 2,3 4)'))) FROM  c

it also crashes if I run:

SELECT sum(ST_LineCrossingDirection(the_geom, ST_GeomFromText('LINESTRING(1 2,3 4)'))) FROM  c limit 1;

But it will not crash if I run:

SELECT sum(ST_LineCrossingDirection(the_geom, ST_GeomFromText('LINESTRING(1 2,3 4)'))) FROM  (select * from c limit 1) d

I don't know enough to understand the internal difference between the two last examples. As I understand it it doesn't wich one of the two rows I put first in the last example so it isn't the lines in itself that crashes the function, but something hangeing there from the last run of the function.

/Nicklas

[nicklas]

I can just add that I tried the above with two identical rows in the table like

create table c as 
SELECT ST_MakeLine(ST_Point(-10,40),ST_Point(40,-10)) As the_geom ;
insert into c 
SELECT ST_MakeLine(ST_Point(-10,40),ST_Point(40,-10)) As the_geom ;

with the same result. it doesn't crash with:

SELECT 
sum(ST_LineCrossingDirection(the_geom, ST_GeomFromText('LINESTRING(1 2,3 4)')))
FROM  (select * from c limit 1) d;

but it crashes with:

SELECT 
sum(ST_LineCrossingDirection(the_geom, ST_GeomFromText('LINESTRING(1 2,3 4)')))
FROM  c;

and:

SELECT 
sum(ST_LineCrossingDirection(the_geom, ST_GeomFromText('LINESTRING(1 2,3 4)')))
FROM  c limit 1;

/Nicklas

[mcayland]

Ah got it - it's a typo in ST_LineCrossingDirection() where the geometry variables aren't being freed correctly :(

Fixed in 1.4 as r4609 and trunk as r4608. Can other people please test and let me know how they get on?

ATB,

Mark.

[robe]

Well it doesn't crash anymore. I get a wonderful answer of -42 when I do this.

SELECT sum(ST_LineCrossingDirection(a.the_geom, b.the_geom)) FROM ((SELECT ST_MakeLine(ST_Point(i,j),ST_Point(j,i)) As the_geom

    FROM generate_series(-10,100,5) As i

        CROSS JOIN generate_series(5,70, 4) As j WHERE NOT(i = j) ORDER BY i, i*j)) As a CROSS JOIN

    ((SELECT ST_MakeLine(ARRAY[ST_Point(i,j),ST_Point(j,i), ST_Point(k,i), ST_Point(j,k)]) As the_geom

        FROM generate_series(-10,10000,1500) As i

            CROSS JOIN generate_series(5,800, 7) As j CROSS JOIN generate_series(0,800, 200) As k WHERE NOT(i = j) AND NOT (j = k) AND NOT (k = i) ORDER BY i, i*j)) As b

WHERE ST_LineCrossingDirection(a.the_geom,ST_GeomFromText('LINESTRING(8 53.54,11 53.54)')) = 1 

But I think there is still a problem.

In our documentation -- We still have this example that doesn't behave right

SELECT ST_LineCrossingDirection(foo.line1, foo.line2) As l1_cross_l2 ,

ST_LineCrossingDirection(foo.line2, foo.line1) As l2_cross_l1

FROM (SELECT

ST_GeomFromText('LINESTRING(25 169,89 114,40 70,86 43)') As line1, ST_GeomFromText('LINESTRING(2.99 90.16,71 74,20 140,171 154)') As line2 ) As foo;

(gives me -2, 0)

 http://www.postgis.org/documentation/manual-svn/ST_LineCrossingDirection.html

So I'll leave this open for now until we figure out why that is giving the presumably wrong answer.

Can't test the hausdorff one yet since don't have 3.2 compiled in on this box.

[mcayland]

Yeah; I see exactly the same answers. Unfortunately though, I can't make much sense of the integer constants in the manual to work out what the function *should* actually be doing. Can anyone explain this in more detail? For example, do the LEFT/RIGHT parts refer to spatial position or the order of the input parameters?

ATB,

Mark.

[robe]

I'm closing this ticket out. I think the server memory issue is resolved and what is left is an artifact in our questionable card counting strategy. I'll put that in as a separate ticket item.