In T74000#879987, @Shay Gusin (shayg) wrote:

Is there a reason to move to the next frame?
As I understand the setting the current frame will also trigger an update.

Hi @Sybren A. Stüvel (sybren), thanks for the update.

That blend file (Food_Apple.blend) is set up incorrectly; the custom property is set on the Scene, but the driver is accessing it on the Object. I have corrected this in

Attached is the file for which there's a problem.
Also this is the code to run:

@Shay Gusin (shayg) please provide a minimal blend file that demonstrates the issue.

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.

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.

Reconfirmed, still an issue

After investigating, I realized that depsgraph calls 3 eval functions in a problematic order.

1. BKE_rigidbody_eval_simulation
2. BKE_object_eval_local_transform
3. BKE_object_eval_uber_data

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.

I have added a note about this in the bpy.app.handlers API documentation.

Confirmed to be caused by 0a95a0852eb1 @Clément Foucault (fclem)

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.

This issue does not seem to be limited to drivers, even if I key value of value node, performance is the same.

Thread:

>	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]

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.

@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.