#316 closed defect (fixed)
IsValid called on invalid 3d object leads to crash
Reported by: | pramsey | Owned by: | mcayland |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 1.5.0 |
Component: | postgis | Version: | master |
Keywords: | Cc: |
Description
Here's the offending SQL
select st_isvalid('POLYGON ((-97.78351581 36.37358796 1167.172,-97.78303556 36.37319923 1167.172,-98.88351581 38.37358796 1167.172))');
Solution should be back-ported into 1.4 also.
Change History (6)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
I can make it crash differently by adding a redundant point (and thereby passing through the minpoints test).
select 'POLYGON ((-97.78351581 36.37358796 1167.172,-97.78303556 36.37319923 1167.172,-97.78303556 36.37319923 1167.172,-98.88351581 38.37358796 1167.172))'::geometry;
comment:4 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I believe this is now fixed in 1.4 branch (r4902) and trunk (r4906). The short story is that due to the way the parser works, not all objects hold position information and so trying to display the error message was causing the crash. I've since altered the pop() function to ensure that the position is stored correctly in so-called "counting tuples" and then rebased the check functions to use these instead, except for the continuous curve check which seems to work slightly differently.
Please give this a thorough test as I'm slightly concerned that I may have missed a few cases.
Paul: I totally agree with you - this took much longer than it really should have done. I'll be the first one there standing in line with a pitchfork when the revolution comes.
comment:5 by , 15 years ago
WRT the revolution, see the proto-parser in my defunct spike. In 2.0 I'm pulling this baby over.
http://svn.osgeo.org/postgis/spike/pramsey/geodetic/liblwgeom/parse/
The problem is in the parsing, not the validity check, so this fails too: