I commented out the C++11 mutex in gdaldrivermanager.cpp
<https://github.com/OSGeo/gdal/pull/164/commits/d1449e2eb5a85a6ec2520ad77ee579015fe14197#diff-e3e90e0089f1b70ddf36ebe89a73a733>
- this helps. OSX CI test passed successfully.
https://travis-ci.org/OSGeo/gdal/jobs/177297023
Best regards,
Dmitry
19.11.16 21:24, 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.roua...@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
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
