[Gdal-dev] OGR/Shapefile crash

[gdal-dev-admin at remotesensing.org]

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?


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.


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?

-- 
Curt Mills, WE7U                    hacker_NO_SPAM_ at tc.fluke.com
Senior Methods Engineer/SysAdmin
"Lotto:    A tax on people who are bad at math!"
"Windows:  Microsoft's tax on computer illiterates!" -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"