[Gdal-dev] OGR/Shapefile crash

[gdal-dev-admin at remotesensing.org]

gdal-dev-admin at remotesensing.org wrote:
> I sent this to Frank directly, then decided to subscribe and post to
> this list instead.  Sorry for the duplicate to you Frank.  I added a
> bit more info in this one though.
> 
> ---------- Forwarded message ----------
> 
> I remember a while back having segfaults with Shapelib when trying
> to open a dataset that was corrupted.  I think that one had too few
> vectors to go with the dbf file.  I had no way around the segfaults,
> which would crash Xastir, other than deleting the corrupted files.
> Also got segfaults if I tried to access a field index that was
> higher than available.
> 
> Question #1, Shapelib:
> ----------------------
> Is there any way to have the Shapefile library incorporate simple
> checks so that segfaults are avoided and error codes are returned
> instead?

Curt,

Is not my intention that shapelib would crash when in response to
normal sorts of invalid arguments.  If you can detail the situation
and submit it via the Shapelib Bugzilla (http://shapelib.maptools.org)
I will look into improving things for the next release.

> Question #2, OGR:
> -----------------
> 
>>As I try to get OGR integrated into Xastir, I'm getting segfaults
>>any time I try to open a Shapefile dataset that includes a .prj
>>file.  Is it something I'm doing, or perhaps the PROJ.4 installation
>>on my system?
> 
> 
>>Note:  Using Xastir with Shapelib, I can open these files.  Using
>>OGR, I can open them.  Once I add the .prj file into the mix,
>>Xastir/OGR segfaults, Xastir/Shapelib can read them just fine.
 >
>>Datum translations using libgeotiff are working fine in Xastir.
>>Datum translations using OGR appear to be working for TIGER/Line
>>files.  We're just having this segfault problem with Shapefile .prj
>>files (so far).  Segfaults are bad for us.  Ours is a long-running
>>program, and we'd like a way around segfaults in all cases.
> 
> 
> Never mind on this one!  On one system with older? GDAL/OGR, it
> segfaulted.  On another system, with CVS GDAL/OGR, it opened it just
> fine with both methods, with a .prj file present.  I'll update the
> other system and things will hopefully be fine there.

Ahh, good.

> Question #3, OGR:
> -----------------
> The available docs for datum translation using OGR are mostly in
> C++.  The text mentions that the Transform() method returns
> OGRERR_NONE on success.  In 'C', I'm getting a '1' returned, but the
> operation appears to succeed otherwise.  Your short 'C' example
> seems to show that '1' is the proper return code as well.  Thoughts?
> Am I doing that one right?

The OGR Projections tutorial was wrong on this point.  The Transform()
method returns TRUE (non-zero) on success or FALSE (zero) on failure.
I will correct the OGR Projection Tutorial.

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent