This is a deadlock for the same reason as in T73516. The closest_point_on_mesh Python function requires an evaluated depsgraph, so you cannot use it in a driver which is evaluated during evaluation.
The deadlock happens because in your backtrace the main thead has the Python GIL and the other thread waits for it. Furthermore the main thread seems to be waiting on the other thread as well.
Sun, Feb 16
I can confirm this. I have the same problem. I have an armature with a mesh parented to it and a properties bone. I tried to drive the visibility of the mesh both in viewport and render and switch between hiding and revealing them using that bone. But I can't hide/reveal them both at same time. Some times they do, sometimes they interchange. In other words, the driver of hiding the mesh in viewport alone works fine with the bone, but if you also drive the rendering, then it bugs and doesn't allow you to hide/reveal them above at the same time, only one at a time. Saving and reloading the file doesn't work for me.
Can confirm, this persists on 2.82.6 and 2.83 alpha.
I have attached a sample file and a demo video.
Fri, Feb 14
Reconfirmed, still an issue
Thu, Feb 13
After investigating, I realized that depsgraph calls 3 eval functions in a problematic order.
Wed, Feb 12
After investigating a little, I realized that the reason for the failure is the Rigdy Body.
There is something wrong with updating the object's matrices in 2.80.
I suspect it is a lack of sync between the evaluated object and the original.
I set this as known issue, because it fixing it might require deeper changes to how Rigid Bodies are implemented in Blender and it is unlikely, that someone is fixing this in the next couple of month.
Tue, Feb 11
I have added a note about this in the bpy.app.handlers API documentation.
Mon, Feb 10
Confirmed to be caused by 0a95a0852eb1 @Clément Foucault (fclem)
Fri, Feb 7
Ok, @Sybren A. Stüvel (sybren) I wasn't aware of that. That fixes the issue for me, both in the minimal provided example and in my rendering setup (at least after testing some example shots).
Try locking the interface (Render → Lock Interface). If this prevents the crash, it's a known threading issue.
Thu, Feb 6
This issue does not seem to be limited to drivers, even if I key value of value node, performance is the same.
> blender.exe!BPY_DECREF(void * pyob_ptr) Line 597 C blender.exe!fcurve_free_driver(FCurve * fcu) Line 2110 C blender.exe!free_fcurve(FCurve * fcu) Line 97 C blender.exe!free_fcurves(ListBase * list) Line 119 C blender.exe!BKE_animdata_free(ID * id, const bool do_id_user) Line 274 C blender.exe!BKE_object_free(Object * ob) Line 513 C blender.exe!DEG::deg_free_copy_on_write_datablock(ID * id_cow) Line 1065 C++ blender.exe!DEG::deg_update_copy_on_write_datablock(const DEG::Depsgraph * depsgraph, const DEG::IDNode * id_node) Line 944 C++ blender.exe!DEG::deg_evaluate_copy_on_write(Depsgraph * graph, const DEG::IDNode * id_node) Line 1080 C++ [Externí kód] [Vložený rámec] blender.exe!std::_Func_class<void,Depsgraph *>::operator()(Depsgraph * <_Args_0>) Line 969 C++ blender.exe!DEG::`anonymous namespace'::evaluate_node(const DEG::`anonymous-namespace'::DepsgraphEvalState * state, DEG::OperationNode * operation_node) Line 117 C++ blender.exe!DEG::`anonymous namespace'::deg_task_run_func(TaskPool * pool, void * taskdata, int thread_id) Line 129 C++ blender.exe!task_scheduler_thread_run(void * thread_p) Line 454 C [Externí kód]
Wed, Feb 5
I would like to add that disabling "Auto smooth" from meshes will increase performance while previewing animation in viewport.
So after playing around with this a little bit more, I get all sorts of strange behavior.
Tue, Feb 4
@Brecht Van Lommel (brecht) the operators from handlers was something I expected myself, but I get also segfaults without any operator involved.
Does it happen also without calling operators from the handler? It wouldn't surprise me if that causes problems, frame change and depsgraph handlers normally should only use direct API functions. Calling operators with associated undo pushes and other scene updates may well break something.
I was able to come up with a minimum example. My more complex code, including modifiers etc. resulted in segfaults with different stacktraces, but I guess it's the same issue triggering it.
It is interesting to note that if you add a modifier to the Circle, the projection on the other object is that of the original Circle plus the modifier.
This makes me suspect that the modifier is being computed for two objects instead of one.
I will merge this report to another one, because it is the same underlying issue.
@Vladimir (evilvoland) indeed this is nice demonstration of inconsistency, so I will reopen this report.
Mon, Feb 3
Just pushed a fix that resolves the crashing issue.
@Aleksandr (viadvena) I just saw that when opening this file in 2.81 there is no crash after "Copy All To Selected Objects" but all smoke flow objects lose their modifier.
@Brecht Van Lommel (brecht) I will put some more time into synthesizing a minimal working example. I was just not able reproduce the segfaults with my first attempt.
I know how to make a simple rotation, but this scene is a simplified option for my rig.
The problem is that either the viewport does not render correctly, or the data is not updated during the rendering, while in version 2.79 everything goes as expected, including rendering (or in version 2.79, too, an error).