Page MenuHome

blender crashes when add a inverse kineatics constraint to bone
Closed, ResolvedPublic


when added a inverse kinematics to a bone it causes a crash.

my OS:
windows 7 ultimate x86
processor: amd phenon 9500 quadcore 2.21GH
nvidia geforce 6050SE nforce 430

blender version:
blender 2.78a hash e8299c8

the bug not is happening in previous versions.

open blender, delete defaut cube and add a single bone, go to edit mode, extrude the bone tree times and duplicate the last bone, unparent it, go to pose mode and add a inferse kinematic constraint setup, uncheck use tail opition, and it will crash blender.

or simply enable auto IK and try editing the pose.

this file crashed blender all times:

console screenshot on exact moment of crash:

sory my bad english.

Event Timeline

Aaron Carlisle (Blendify) lowered the priority of this task from Unbreak Now! to 90.Nov 1 2016, 4:01 PM
Jean Da Costa (jeacom256) renamed this task from blender crashes when add a inverse kineatics constraint is added to bone to blender crashes when add a inverse kineatics constraint to bone.Nov 2 2016, 3:05 PM
Jean Da Costa (jeacom256) updated the task description. (Show Details)

I could not reproduce maybe an 32-bit thing?

It's a mem alignment issue in bf_intern_iksolver, none of the classes care about their alignment, yet they use eigen which really wants them to be aligned at 16 byte boundaries (for vectorization reasons) , this can be fixed by overriding the class new and delete operators like this

	void* operator new(size_t i)
		return _mm_malloc(i, 16);

	void operator delete(void* p)

But it feels a little dirty to cut / paste that all over the place? Given this is not the only place in blender plagued by this (ge_phys_bullet ge_converter and bf_intern_libmv emit similar warnings, for at total of 20+ classes in blender that have this issue ), Bullet is by far the worst offender, and in never versions they solved it with a macro like this

Sergey, what's the preferred way of addressing this in blender?

We can have something similar, yes.

Did you check if using aligned attribute on class and/or property helps?

It doesn't, it only really helps for things that are allocated at compile time the docs ( ) mention

Note that ordinary allocators—for example, malloc, C++ operator new, and the Win32 allocators—
return memory that is usually not sufficiently aligned for __declspec(align(#)) structures or arrays of structures. 
To guarantee that the destination of a copy or data transformation operation is correctly aligned, use _aligned_malloc, or write your own allocator.

Hrm, so we'll need to do aligned-alloc for those classes. For that doing something what you showed should work (we should be able to use EIGEN_MAKE_ALIGNED_OPERATOR_NEW).

However, not sure that will be enough. Thing is, even object itself is aligned it doesn't mean its properties are aligned, so guess alignment attribute is still needed?

Judging from the eigen classes have aligned attributes on them, so the structure layout will be aligned at compile time. EIGEN_MAKE_ALIGNED_OPERATOR_NEW makes sure that whenever you new up a class it'll be aligned as well.

Bastien Montagne (mont29) lowered the priority of this task from 90 to 50.