id summary reporter owner description type status priority milestone component version severity resolution keywords cc 3225 Potential - small - race condition in gdalrasterband.cpp ? Even Rouault warmerdam "Frank, While reviewing #3224, I ended up reviewing the current implementation in gdalrasterband.cpp and (I think) I've discovered a (probably very hard-to-hit) race condition. The scenario is Thread 1 flushing a block (from FlushCacheBlock() for example) while Thread 2 calling TryGetLockedBlockRef() on the same block. Below a potential executation flow that could lead to crashes : {{{ Thread 1 Thread 2 FlushBlock() TryGetLockedBlockRef() 1000: GDALRasterBlock::SafeLockBlock( papoBlocks + nBlockIndex ); 1117: GDALRasterBlock::SafeLockBlock( papoBlocks + nBlockIndex ); 1119: return papoBlocks[nBlockIndex]; 1002: poBlock = papoBlocks[nBlockIndex]; 1003: papoBlocks[nBlockIndex] = NULL; ..... 1049: delete poBlock; XXXX : uses non value returned by line 1119, which is now destroyed }}} The scope of the mutex in SafeLockBlock() is not sufficient. The same applies for the sub-blocking case, so there should be a mutex protecting lines 1000-1003, 1014-1029, 1117-1119 and 1125-1142 " defect closed normal 2.0.0 default unspecified normal fixed