Page MenuHome

Crash with animated b-bone segments
Open, Confirmed, HighPublic


Blender Version
Broken: 2.79b

Short description of error
I'm trying to animate using a linked (proxy) rig, but it keeps crashing. It would crash as I'm working in the scene, but it would also crash when opening the scene.

The thing is, the crash seems to be a bit random.
Even if the scene crashes on start, if I keep opening the file, sometimes, it won't crash. It's like playing a crash lottery every time I open the scene.

I figured out that if I delete the character geometry, it doesn't crash. If I append the rig, it doesn't crash.
However, if I attach any geometry to the linked rig, it seems to crash.

Including an example file:

To get it to crash:

  1. Open up the attached file.
  2. Scrub timeline back and forth.

If you're (un)lucky, you might find that the file crashes on open. In that case, just keep trying to open the file.

Note that if you delete the geometry, it doesn't crash.



Event Timeline

Philipp Oeser (lichtwerk) triaged this task as Needs Information from User priority.Feb 8 2019, 11:19 AM

Please also provide the library .blend (//Exit_Rig/Exit_EXIT_06.blend)

Ah, that makes sense, sorry about that.

Here it is:

Philipp Oeser (lichtwerk) raised the priority of this task from Needs Information from User to Needs Triage by Developer.Feb 8 2019, 8:59 PM
Sebastian Parborg (zeddb) triaged this task as Confirmed, Medium priority.Feb 9 2019, 3:30 PM


Thread 25 "blender" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd4bfe700 (LWP 15704)]
0x000055555682edfb in b_bone_deform (co=co@entry=0x7fffd4bfd380, dq=dq@entry=0x0, defmat=defmat@entry=0x0, bone=<optimized out>, bone=<optimized out>,
    pdef_info=<optimized out>, pdef_info=<optimized out>) at /home/zed/programmering/blender_master/blender/source/blender/blenkernel/intern/armature.c:929
929		a = (int)(y / segment);
(gdb) bt
#0  0x000055555682edfb in b_bone_deform (co=co@entry=0x7fffd4bfd380, dq=dq@entry=0x0, defmat=defmat@entry=0x0, bone=<optimized out>, bone=<optimized out>,
    pdef_info=<optimized out>, pdef_info=<optimized out>) at /home/zed/programmering/blender_master/blender/source/blender/blenkernel/intern/armature.c:929
#1  0x00005555568338b4 in pchan_bone_deform (contrib=<synthetic pointer>, co=0x7fffd10b6e84, mat=0x0, dq=0x0, vec=<optimized out>, weight=0.00517571345,
    pdef_info=<optimized out>, pchan=0x7fffd0839a88) at /home/zed/programmering/blender_master/blender/source/blender/blenkernel/intern/armature.c:1074
#2  armature_deform_verts (armOb=0x7fffe89fde08, target=target@entry=0x7fffe89fe408, mesh=mesh@entry=0x0, vertexCos=vertexCos@entry=0x7fffd10b6008,
    defMats=defMats@entry=0x0, numVerts=numVerts@entry=527, deformflag=1, prevCos=0x0, defgrp_name=0x7fffd102d188 "", gps=0x0)
    at /home/zed/programmering/blender_master/blender/source/blender/blenkernel/intern/armature.c:1330
#3  0x00005555565ed33f in deformVerts (md=0x7fffd102d108, ctx=0x7fffd4bfd6e0, mesh=0x0, vertexCos=0x7fffd10b6008, numVerts=527)
    at /home/zed/programmering/blender_master/blender/source/blender/modifiers/intern/MOD_armature.c:113
#4  0x000055555681f40a in mesh_calc_modifiers (depsgraph=depsgraph@entry=0x7fffe43fd608, scene=scene@entry=0x7fffd8260008, ob=ob@entry=0x7fffe89fe408,
    inputVertexCos=inputVertexCos@entry=0x0, useDeform=useDeform@entry=1, need_mapping=need_mapping@entry=false, dataMask=637747721, index=-1, useCache=true,
    build_shapekey_layers=false, r_deform=0x7fffe89fe958, r_final=0x7fffe89fe950)
    at /home/zed/programmering/blender_master/blender/source/blender/blenkernel/intern/DerivedMesh.c:1236
#5  0x00005555568200f1 in mesh_build_data (depsgraph=depsgraph@entry=0x7fffe43fd608, scene=scene@entry=0x7fffd8260008, ob=ob@entry=0x7fffe89fe408,
    dataMask=637747721, build_shapekey_layers=build_shapekey_layers@entry=false, need_mapping=<optimized out>)
    at /home/zed/programmering/blender_master/blender/source/blender/blenkernel/intern/DerivedMesh.c:2033
#6  0x000055555682233b in makeDerivedMesh (depsgraph=depsgraph@entry=0x7fffe43fd608, scene=scene@entry=0x7fffd8260008, ob=ob@entry=0x7fffe89fe408,
    em=em@entry=0x0, dataMask=<optimized out>, dataMask@entry=637747721, build_shapekey_layers=build_shapekey_layers@entry=false)
    at /home/zed/programmering/blender_master/blender/source/blender/blenkernel/intern/DerivedMesh.c:2149
#7  0x0000555556927087 in BKE_object_handle_data_update (depsgraph=0x7fffe43fd608, scene=0x7fffd8260008, ob=0x7fffe89fe408)
    at /home/zed/programmering/blender_master/blender/source/blender/blenkernel/intern/object_update.c:182
#8  0x000055555692744e in BKE_object_eval_uber_data (depsgraph=0x7fffe43fd608, scene=0x7fffd8260008, ob=0x7fffe89fe408)
    at /home/zed/programmering/blender_master/blender/source/blender/blenkernel/intern/object_update.c:355
#9  0x0000555556bcb040 in std::function<void (Depsgraph*)>::operator()(Depsgraph*) const (__args#0=<optimized out>, this=0x7fffce0e79e8)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include/g++-v8/bits/std_function.h:682
#10 DEG::deg_task_run_func (pool=0x7fffc7bd5008, taskdata=0x7fffce0e7988, thread_id=2)
    at /home/zed/programmering/blender_master/blender/source/blender/depsgraph/intern/eval/
#11 0x0000555556bac8b1 in handle_local_queue (thread_id=2, tls=0x7fffd8281078)
    at /home/zed/programmering/blender_master/blender/source/blender/blenlib/intern/task.c:416
#12 task_scheduler_thread_run (thread_p=0x7fffd8281068) at /home/zed/programmering/blender_master/blender/source/blender/blenlib/intern/task.c:445
#13 0x00007ffff63923c3 in start_thread () from /lib64/
#14 0x00007ffff13493ef in clone () from /lib64/

If that's the case i'd like @Alexander Gavrilov (angavrilov) to have a look first. He knows the cache implementation details better.

This rig is using a driver on bbone_segments that depends on the deformation of the rig. Dependency graph doesn't handle this, and I doubt it can do it in a reasonable way, since the segment count affects the graph itself. I fixed this from crashing by adding some checks, but the actual problem is still there.

@Alexander Gavrilov (angavrilov), hrm. Sounds like actual solution would be to forbid driving/animating the segment count. Not sure we can realistically do something better here?

It could be the safest solution. Driving the setting could be useful for something like controlling settings of multiple bones from one custom property, but it certainly mustn't be animated.

Currently depsgraph doesn't seem to even be creating any dependencies from those drivers - that was probably somewhat ok when b-bone shape was evaluated from scratch every time it was used, but now that it is a proper depsgraph node, that definitely isn't right. The fact that those nodes in the graph are only created when the segment count is not 1 complicates things even more, so with this set up that property probably has to be blocked from being animated.

If the B-Bone/not B-Bone switch was a separate setting it can probably be animated if proper dependencies are added into depsgraph (and with some care to handle mismatched data without crashing in case of dependency loops).

Basically, the only ways to allow animating the segment count is to either split the B-Bone toggle into a separate non-animatable checkbox, or have the depsgraph build code somehow detect that the property is animated or has a driver, and treat it as a B-Bone even if the current value is 1.

Brecht Van Lommel (brecht) renamed this task from Blender crashes when adding geometry to linked rig and animation to Crash with animated b-bone segments.Mar 14 2019, 7:10 PM

What is the use case for animating the number of segments?

Sometimes it is useful when switching between curved and hard-shaped joints in a rig

@Jacques Lucke (JacquesLucke) In the file provided in T62364: 2.8 | Keyframes on BBones cause crash I used segmentation animation in the foreArm and upperArm to go from a bendy effect to an angular one. I acknowledge that that's not a standardized way of rigging bendy joints. However, the ability to key the segments would imply that a user should be able to use it in such a case.

I see, are there other/better solutions for this in Blender?

Rigify super_finger uses keys on the ease in/out properties.

Brecht Van Lommel (brecht) raised the priority of this task from Confirmed, Medium to Confirmed, High.Mon, Apr 1, 1:43 PM