This mesh_new_from_curve_type_object area is pretty awful, but I think this bug is just about finding the right situations to free original and evaluated data, the fix shouldn't be too bad.

We are actually getting the right subframe in BKE_object_modifier_update_subframe, guess BKE_animsys_evaluate_animdata has some loose parts in concert with geonodes?

Setting as a dependency graph bug since the creation of an evaluated mesh depends on the collection order.

Thanks for the report. Marking this as known issue since it depends on the rigid body system which at the moment has no active developer. I'm tagging Sergej here anyways in case he wants to tackle any of those. Anyone wlse interested on that can also join the geometry nodes meetings to get onboarded.

My earlier analysis wasn't quite correct, as it turns out adding an RNAPathKey relation already does the RNA path parsing. The crash seems to be caused by the changed semantics of object.data: before rB56407432a6aa it was safe to use when the pointer is valid, so even when the data it points to was not yet evaluated properly. This has now changed, but the depsgraph relations haven't been updated to account for this.

@Sergey Sharybin (sergey) thanks, will commit fix then

Would consider this a known issue for now, given how old it is, and considering that fixing it would probably be quite involved...

@Bastien Montagne (mont29) Using DEG_id_tag_update_ex instead of BKE_sound_load is correct. The only thing is that flag should just be ID_RECALC_AUDIO. Basically you almost never want to use explicit ID_RECALC_COPY_ON_WRITE.

This call to BKE_sound_load looks horribly old (from 2008! code) and wrong to me in context of new evaluation with depsgraph, I would expect rather something like that here:

Thanks for the info.

@Sybren A. Stüvel (sybren), I vaguely remember the issue. Also remember some work was done on it. The crash is never good, and it is not an implicit design limitation of drivers referring to other IDs. In contrast, it should be totally possible to reference any ID from the expression. Think either we are missing a relation, or we need to do something special to keep shapekeys on the result so that values can be used from them (the latter one is AFAIR the patch you've worked on a while ago. Think it was committed but some of the optimization work later one might have undone it).

In T96289#1321103, @naoki yamamoto (nao000) wrote:

Sorry to keep writing additional information.

Can confirm

It should also most definitely be tagged as depsgraph issue...

TODO: rebase and check that it still works or whether it has been fixed already.

[Edited to correct] I presume modifier visibility is rarely used by drivers, although possibly heavily by some users / in some projects.