Page MenuHome

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

Description

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.

steps
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:



https://www.youtube.com/watch?v=yce51lIKgvU&feature=youtu.be

sory my bad english.

Event Timeline

Aaron Carlisle (Blendify) lowered the priority of this task from Unbreak Now! to Needs Triage by Developer.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.

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)
	{
		_mm_free(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

http://www.letworyinteractive.com/blendercode/d0/d6b/btScalar_8h.html#a0bd5b84db13a000ac43fffe2bfc32187

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?

LazyDodo (LazyDodo) added a comment.EditedNov 3 2016, 10:23 PM

It doesn't, it only really helps for things that are allocated at compile time the docs ( https://msdn.microsoft.com/en-us/library/83ythb65.aspx ) 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 https://eigen.tuxfamily.org/dox-devel/group__TopicStructHavingEigenMembers.html 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) triaged this task as Confirmed, Medium priority.