Fix T52823: New Depsgraph - Shrinkwrap crashes blender
The issue was caused by threading conflict around looptris: it was possible that DM will return non-NULL but non-initialized array of looptris. Thanks Campbell for second pair of eyes!
This commit is contained in:
parent
495d3c8dd7
commit
1a4442b3db
@ -94,7 +94,7 @@ static DerivedMesh *navmesh_dm_createNavMeshForVisualization(DerivedMesh *dm);
|
||||
#endif
|
||||
|
||||
|
||||
static ThreadMutex loops_cache_lock = BLI_MUTEX_INITIALIZER;
|
||||
static ThreadRWMutex loops_cache_lock = PTHREAD_RWLOCK_INITIALIZER;
|
||||
|
||||
|
||||
static void add_shapekey_layers(DerivedMesh *dm, Mesh *me, Object *ob);
|
||||
@ -241,19 +241,26 @@ static int dm_getNumLoopTri(DerivedMesh *dm)
|
||||
|
||||
static const MLoopTri *dm_getLoopTriArray(DerivedMesh *dm)
|
||||
{
|
||||
if (dm->looptris.array) {
|
||||
MLoopTri *looptri;
|
||||
|
||||
BLI_rw_mutex_lock(&loops_cache_lock, THREAD_LOCK_READ);
|
||||
looptri = dm->looptris.array;
|
||||
BLI_rw_mutex_unlock(&loops_cache_lock);
|
||||
|
||||
if (looptri != NULL) {
|
||||
BLI_assert(dm->getNumLoopTri(dm) == dm->looptris.num);
|
||||
}
|
||||
else {
|
||||
BLI_mutex_lock(&loops_cache_lock);
|
||||
BLI_rw_mutex_lock(&loops_cache_lock, THREAD_LOCK_WRITE);
|
||||
/* We need to ensure array is still NULL inside mutex-protected code, some other thread might have already
|
||||
* recomputed those looptris. */
|
||||
if (dm->looptris.array == NULL) {
|
||||
dm->recalcLoopTri(dm);
|
||||
}
|
||||
BLI_mutex_unlock(&loops_cache_lock);
|
||||
looptri = dm->looptris.array;
|
||||
BLI_rw_mutex_unlock(&loops_cache_lock);
|
||||
}
|
||||
return dm->looptris.array;
|
||||
return looptri;
|
||||
}
|
||||
|
||||
static CustomData *dm_getVertCData(DerivedMesh *dm)
|
||||
|
Loading…
Reference in New Issue
Block a user