Re: [gdal-dev] ogr2ogr bug with dwg file
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@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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ogr2ogr bug with dwg file
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? 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). 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.ht ml Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] ogr2ogr bug with dwg file
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.
Is there anyone else having the similar experience? I am thinking of adding
OGRCleanupAll(); before exit(1); in the following ogr2ogr.cpp code:
/if( !TranslateLayer( poDS, poPassedLayer, poODS, papszLCO,
pszNewLayerName, bTransform, poOutputSRS,
bNullifyOutputSRS,
poSourceSRS, papszSelFields, bAppend,
eGType,
bOverwrite, eGeomOp, dfGeomOpParam,
papszFieldTypesToString,
nCountLayerFeatures, bWrapDateline,
poClipSrc, poClipDst,
bExplodeCollections, pszZField, pszWHERE,
pfnProgress, pProgressArg))
{
CPLError( CE_Failure, CPLE_AppDefined,
Terminating translation prematurely after
failed\n
translation from sql statement. );
exit( 1 );
}/
Best regards,
Xian
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/ogr2ogr-bug-with-dwg-file-tp5065611.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ogr2ogr bug with dwg file
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.ht
ml Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Geospatial professional services
http://even.rouault.free.fr/services.html
Index: gcore/gdaldllmain.cpp
===
--- gcore/gdaldllmain.cpp (revision 26157)
+++ gcore/gdaldllmain.cpp (working copy)
@@ -107,11 +107,13 @@
}
else if (dwReason == DLL_PROCESS_DETACH)
{
+CPLSetConfigOption(IN_GDAL_GLOBAL_DESTRUCTOR, YES);
::GDALDestroyDriverManager();
#ifdef OGR_ENABLED
::OGRCleanupAll();
#endif
+CPLSetConfigOption(IN_GDAL_GLOBAL_DESTRUCTOR, NULL);
}
return 1; // ignroed for all reasons but DLL_PROCESS_ATTACH
Index: ogr/ogrsf_frmts/dwg/ogrdwgdriver.cpp
===
--- ogr/ogrsf_frmts/dwg/ogrdwgdriver.cpp (revision 26157)
+++ ogr/ogrsf_frmts/dwg/ogrdwgdriver.cpp (working copy)
@@ -53,7 +53,8 @@
OGRDWGDriver::~OGRDWGDriver()
{
-if( bInitialized )
+if( bInitialized !CSLTestBoolean(
+CPLGetConfigOption(IN_GDAL_GLOBAL_DESTRUCTOR, NO)) )
{
bInitialized = FALSE;
odUninitialize();
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
