Differential D13411
Fix T91912: Crash on deleting driver Authored by Sybren A. Stüvel (sybren) on Nov 29 2021, 4:11 PM. Tags None Subscribers None
Details
When there are multiple depsgraphs (for example the main one + a separate one for rendering or VSE precaching) and a driver is removed, only the main depsgraph gets told to reconstruct its relations. This causes evaluation of the by-now-removed driver in the other depsgraphs. A proper fix would be to get the background jobs to refresh their depsgraph as well (or to abort/restart), but that's too big of a change for Blender 3.0. This at least fixes the crash.
Diff Detail
Event TimelineComment Actions I'm not really sure about this one. There are much more cases when modifications in the main database would cause issues with the background depsgraph. For the rendering it is done by special lock hapenning at the time while depsgraph needs to do such access. For the background jobs like prefetch what I'd expect happening instead is that the depsgraph used for prefetch is created on the main thread, the copy-on-write is to happen from the main thread as well, and ever after that it should never access original data. Not sure this is manageable complexity of a change for 3.0 though. Btw, if the driver is removed from sequence the prefetch is to be stopped and not to be trusted, because it will correspond to the wrong state of strip. How this is supposed to be handled? Comment Actions This still crashes here, because fcu_orig->rna_path points to uninitialized memory. Seems that is the case for fcu_orig->array_index too. Comment Actions Original data is only allowed to be touched by active dependency graph. The prefetch depsgraph is not supposed to be active. |