[gdal-dev] Building with SEH

[Chris Howell]

Hi Martin,

Thanks for your suggestion. You raise an a good point and I suspect that
it is indeed a null pointer. However my issue is with an application
built on top of GDAL if this is an issue now. I can fix this one off
issue in the OGR commit my changes back and all is well. However the
users of my company's application aren't going to understand that the
file is corrupted and the file driving engine, developed by a third
party, they're going to see a crash as something wrong with software.
They may or may not comment on every file they can't open or every crash
that happens. My experience is they will not. Fixing this one issue is
good and I am all to happy to do it. However in general it's not as
robust of an error handling scheme as we need to have in our
application. Therefore I still think it's better to make use of
Structured Exception Handling. Which allows us my company the most
robust error handling scheme that we can provide and saves our face when
our users are using the software.

Cheers
Chris Howell

mchapman at texelinc.com wrote:
> Chris,
>
> I would handle an error like this by stepping through the gdal source code file with your debugger and try to see what line and what file it is crashing on.  Is the gdal .pdb file in the same directory as your application exe? Are you able to step into the gdal source with your debugger on the call that crashes gdal (f11)? There is most likely a null pointer being used somewhere is my guess.  If you can't solve it send me the bad shape file and I will look at it.
>
> Best regards,
> Martin
>
> Sent via BlackBerry by AT&T
>
> -----Original Message-----
> From: "Chris Howell" <chowell at pyxisinnovation.com>
>
> Date: Tue, 11 Mar 2008 22:25:20 
> To:<gdal-dev at lists.osgeo.org>
> Subject: [gdal-dev] Building with SEH
>
>
> Hi All,
>  
>  Currently there is an error with one of the drivers in OGR whereby if a corrupted or just generally malformatted shape file is attempted to be opened through OGR, there is an exception that is generated in the VC Runtime, where OGR completely crashes and I can't trap the exception to handle it at application level because the runtime is crashing. What I am wondering about is there a way I can compile GDAL with SEH enbabled turning exceptions that are generated at the OS level into standard C++ exceptions I can trap and handle appropriately ? I looked in the make file and the options file and didn't seen anything obvious.
>  
>  Any light anyone can shed on this would be greatly appreciated.
>  
>  Cheers
>  Chris Howell
>  Software Engineer
>  the PYXIS innovation
>  www.pyxisinnovation.com
>  _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>   
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition. 
> Version: 7.5.516 / Virus Database: 269.21.4/1313 - Release Date: 3/5/2008 9:50 AM
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20080312/8e2af9b0/attachment-0001.html