Corrupted Shapefile causes buffer overflows, assetions etc.

[marisn]

One of my students managed to create a slightly corrupted shapefile. ArcGIS and QuantumGIS manage to deal with this file. OGR reports one of points having coordinates 0,0. File extent is reported as correct one - corrupted point lies outside of extent. Tested on Gentoo ~AMD64.

Part of OGRINFO output:

Layer name: augstumpunkti1
Geometry: Point
Feature Count: 60
Extent: (520046.672571, 6302258.489785) - (576734.883380, 6313825.790398)
Layer SRS WKT:
PROJCS["GRS_1980_Transverse_Mercator",
    GEOGCS["GCS_GRS_1980",
        DATUM["Not_specified_based_on_GRS_1980_ellipsoid",
            SPHEROID["GRS_1980",6378137.0,298.257222101]],
        PRIMEM["Greenwich",0.0],
        UNIT["Degree",0.0174532925199433]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["False_Easting",500000.0],
    PARAMETER["False_Northing",0.0],
    PARAMETER["Central_Meridian",24.0],
    PARAMETER["Scale_Factor",0.9996],
    PARAMETER["Latitude_Of_Origin",0.0],
    UNIT["Meter",1.0]]
....
OGRFeature(augstumpunkti1):43
  Id (Integer) = 0
  augstums (Real) =      80.00000000000
  POINT (563662.082802134566009 6309812.449835392646492)

OGRFeature(augstumpunkti1):44
  Id (Integer) = 0
  augstums (Real) =      90.00000000000
  POINT (0 0)

OGRFeature(augstumpunkti1):45
  Id (Integer) = 0
  augstums (Real) =      82.80000000000
  POINT (565468.073194714379497 6308844.121653324924409)

GRASS 7 imports this file just fine, but almost everything touching this file fails.

v.out.ascii

563662.08280213|6309812.44983539|44
-179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368|-179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368|45
565468.07319471|6308844.12165332|46

v.in.ogr in 6.5:

Building topology for vector map <augst3_tmp>...
Registering primitives...
v.in.ogr: split_q.c:69: RTreeClassify: Assertion `!p->taken[i]' failed.
Aborted

[marisn]

Sample file for testing

[neteler]

I imported the attached file into GRASS 70: v.in.ogr worked. Then I tried

v.out.ascii augstumpunkti1
...
*** glibc detected *** v.out.ascii: realloc(): invalid next size: 0x0000000001409a00 ***
...

It crashes in GRASS 7.svn r52794 in lib/vector/Vlib/ascii.c, line 529 (G_rasprintf())

Import with 6.4.svn still fails:

GRASS 6.4.3svn (PERMANENT):/tmp/broken_shapefile > v.in.ogr augstumpunkti1.shp out=augstumpunkti1 --o
WARNING: Datum <Not_specified_based_on_GRS_1980_ellipsoid> not recognised
         by GRASS and no parameters found
Projection of input dataset and current location appear to match
WARNING: Vector map <augstumpunkti1> already exists and will be overwritten
Layer: augstumpunkti1
Counting polygons for 60 features...
Importing map 60 features...
 100%
-----------------------------------------------------
Building topology for vector map <augstumpunkti1_tmp>...
Registering primitives...
v.in.ogr: split_q.c:69: RTreeClassify: Assertion `!p->taken[i]' failed.
Aborted (core dumped)

[mmetz]

Replying to neteler:

I imported the attached file into GRASS 70: v.in.ogr worked. Then I tried

v.out.ascii augstumpunkti1
...
*** glibc detected *** v.out.ascii: realloc(): invalid next size: 0x0000000001409a00 ***
...

Fixed in trunk r52805. OGR seems to know the correct extents, so v.in.ogr uses these extents as spatial filter. The bogus point is now skipped. Of course the spatial option and -r flag are still respected. Backport? Or are such broken input data too rare?

Markus M