Deadlock with msAcquireLock( TLOCK_GDAL ) on posix(linux) systems

[warmerdam]

I get a lockup that looks like this:

#3  0x000000000044a33c in msAcquireLock (nLockId=2) at mapthread.c:209
(gdb) up
#4  0x00000000004d23b0 in msRASTERLayerGetExtent (layer=0x7e5ea0, extent=0x7fff60aeb9b0) at maprasterquery.c:1337
(gdb) 
#5  0x00000000004476f5 in msLayerGetExtent (layer=0x7e5ea0, extent=0x7fff60aeb9b0) at maplayer.c:285
(gdb) up
#6  0x00000000004a631a in msOWSGetLayerExtent (map=0x7de080, lp=0x7e5ea0, namespaces=0x5a9cdb "MFCO", ext=0x7fff60aeb9b0) at mapows.c:1423
(gdb) up
#7  0x000000000055194d in msGetGDALGeoTransform (hDS=0x981760, map=0x7de080, layer=0x7e5ea0, padfGeoTransform=0x7fff60aebb50) at mapdrawgdal.c:1688
(gdb) up
#8  0x0000000000529ef1 in msDrawRasterLayerLow (map=0x7de080, layer=0x7e5ea0, image=0x7f0d80) at mapraster.c:1535
(gdb) 

The problem is that msGetGDALGeoTransform may have to acquire the TLOCK_GDAL in msRASTERLayerGetExtent() but msDrawRasterLayerLow() already holds the lock. The problem was likely introduced at the code sprint, after 5.4 release but likely does affect the 5.6 betas. I believe only the unix/posix locks are non-reentrant, and it only bites if --with-threads is enabled.

[warmerdam]

Corrected in trunk (r9372).

[warmerdam]

I have confirmed trunk is 5.6 for now, so this is good for 5.6 and I don't believe 5.4 is affected.