> I don't think this comes from GDALPam, but rather from the lower level > machinery of GDALRasterBand & GDALRasterBlock. As I said before, multi- > threaded writing has never properly worked and I'm not sure if the issue > you see is just an implementation bug or a design bug.
OK, after investigation, it was just an implementation bug. A lack of mutex in GetLockedBlock() that caused IReadBlock() & IWriteBlock() to be called from 2 different threads on the same dataset. Fixed per https://trac.osgeo.org/gdal/ticket/6665 I think the issue was mostly due to using the low level GetLockedBlock()/MarkDirty()/DropLock() interfaces, and that people using RasterIO(GF_Read/GF_Write) should be immune to that bug due to locks being already taken at that stage. Anyway fixed now (with a new test case similar to yours). Thanks for the reproducers. Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
