[gdal-dev] CAD (DWG) Driver

[Even Rouault]

On samedi 19 novembre 2016 10:06:26 CET Kurt Schwehr wrote:
> I'm really not sure.

Not sure that the crash mentionned by Dmitry is related to that ? It looks 
like a really good canditate to me. That's the only C++11 mutex in GDAL, with 
2  other ones in the GeoTIFF driver (and those are likely not triggered at 
process termination)

> 
> You can certainly try removing that C++11 mutex.  It was added based on the
> comment at that point in the code.  We'll just have to keep an eye out for
> possible occasional flakes.  If that's the case, we'll need to carefully
> work through the logic and try to figure out a solution that works for
> everything.

I doubt we will see flakes related to that. The mutex was added to prevent 
races in GDALDestroyDriverManager(), but I'm not aware of code in GDAL and its 
utilities that would call it from several threads. And the function has always 
been documented as thread-unsafe.

> 
> +1 for getting the driver into the tree.  It will be easier to make
> additional changes to either it or GDAL with it in the same tree.
> 
> On Sat, Nov 19, 2016 at 8:49 AM, Even Rouault <even.rouault at spatialys.com>
> 
> wrote:
> > On samedi 19 novembre 2016 19:34:02 CET Dmitry Baryshnikov wrote:
> > > Hi Even,
> > > 
> > > The big_endian test now is ok. But osx crash at the exiting of python
> > > after all test finished successfully.
> > > 
> > > This is error message:
> > > 
> > > libc++abi.dylib: terminating with uncaught exception of type
> > > std::__1::system_error: mutex lock failed: Invalid argument
> > > ./gdal/ci/travis/osx/script.sh: line 13: 56363 Abort trap: 6
> > > python run_all.py
> > > 
> > > I find out that this may be the result of resources free order:
> > > https://github.com/dmlc/mxnet/issues/309
> > > https://github.com/google/benchmark/issues/52
> > > 
> > > No idea why this occurred then C++11 used. I'll try to use osx CI test
> > > disabling the CAD driver to exclude this possible issue.
> > 
> > Hum, I think this might be indeed an issue with resource free order
> > between
> > the GDALDestroy() destructor function (in gcore/gdaldllmain.cpp) and the
> > static C++11 mutex Kurt introduced in
> > https://github.com/OSGeo/gdal/commit/a9b947d6850d496f09e668f4cd1488
> > 26d45d9fa9
> > 
> > If this mutex gets destroyed before GDALDestroy() is called, then things
> > might
> > indeed crash.
> > 
> > I think we should remove this static C++11 mutex. Kurt ?
> > 
> > (Another option would be to remove the library destructor function. I've
> > the
> > feeling they cause more harm than good.)
> > 
> > --
> > Spatialys - Geospatial professional services
> > http://www.spatialys.com


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com