[gdal-dev] ogr2ogr bug with dwg file
Even Rouault
even.rouault at mines-paris.org
Mon Jul 15 11:36:31 PDT 2013
Le lundi 15 juillet 2013 04:23:30, Xian Chen/陈羡 a écrit :
> Hi Even,
>
> Thanks for your quick response. I tested your patch on OGR2OGR. All right,
> the application does not crash now. Does that mean with this patch we
> don't need to call OGRCleanupAll() mandatorily?
Well, OGRCleanupAll() is advised to be called to clean up things properly
(mainly if you use a memory debugger, to avoid GDAL memory to be reported as
leaking). What is really compulsory is to destroy datasources so that they get
properly closed.
>
> I am asking this question because we have our own Windows application
> developed based on GDAL/OGR. If we include OGR_DWG.dll the application
> will always crash when exiting (the application called OGRCleanupAll()
> explicitly).
Hum, this is not supposed to happen. So my hypothesis was not completely right
(neither wrong). It seems that it is the destructor of the DWG driver that
causes problem, be it called explicitely or implicitely... I'm not in position
to debug this, so it would be interesting to know if every user of the DWG
driver encounters this, or if it might not come from the way how your GDAL
binaries have been built.
>
> Best Regards,
> Xian
>
> Le jeudi 11 juillet 2013 09:33:36, Xian Chen a écrit :
> > Hi all,
> >
> > Finally I've got a chance to report something after one-month silence as
> > a newcomer in the community.
> > After running ogr2ogr (on Windows 7) to convert a dwg file into shape
> > files, I received an error message as follows:
> > / Warning 6: Normalized/laundered field name: 'ExtendedEntity' to
> > 'ExtendedEn'
> >
> > Warning 6: Normalized/laundered field name: 'EntityHandle' to
> >
> > 'EntityHand'
> >
> > ERROR 1: Attempt to write non-linestring (POINT) geometry to ARC type
> >
> > shapefile.
> >
> > ERROR 1: Terminating translation prematurely after failed
> > translation of layer entities (use -skipfailures to skip errors)/
> >
> > And then the application exited abnormally. I read the source code and
> > found that the last error message was produced by an error from
> > TranslateLayer(). The application terminated there without calling
> > OGRCleanupAll()
> >
> > Therefore I tested reading dwg file on OGR. My conclusion is that
> > OGRCleanupAll() has to be called explicitly before termination of the
> > whole application, otherwise an abnormal termination (due to stack
> > overflow??) will occur.
>
> Hi Xian,
>
> Interesting.
>
> Yes calling OGRCleanupAll() is a best practice, and probably that even the
> error code paths in the utilities should call it, but it shouldn't be
> compulsory to call it.
>
> Looking at the code of the DWG driver, I see that the driver has indeed
> code in its destructor to call the odUninitialize() function. When you
> call OGRCleanupAll() then this code is called. But GDAL has also a DLL
> clean-up code that will call OGRCleanupAll(). I suspect that in that case,
> some C++ automatic objects normally cleaned by odUninitialize() have
> already been destroyed, and at the time odUninitialize() is called, it
> will access them at the time where they are no longer available. Hence the
> crash.
>
> Being not in position to test it myself, in order to confirm my above
> guess, could you revert your changes in ogr2ogr.cpp and test the attached
> patch (based on GDAL trunk) ?
>
> Best regards,
>
> Even
>
> > --
> > View this message in context:
> > http://osgeo-org.1560.x6.nabble.com/ogr2ogr-bug-with-dwg-file-tp5065611.h
> > t ml Sent from the GDAL - Dev mailing list archive at Nabble.com.
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> --
> Geospatial professional services
> http://even.rouault.free.fr/services.html
--
Geospatial professional services
http://even.rouault.free.fr/services.html
More information about the gdal-dev
mailing list