(iTaSC) Assertion failure in jntarray.cpp on Linux (2) #31544

Closed
opened 2012-05-20 20:23:17 +02:00 by Felix Nawothnig · 3 comments

Relates to: #31430

%%%I'm resubmitting this as a bug related to #31430 because I don't see a way to reopen my own bug report...

The attached patch to #31430 (which was committed according to the comments) does not fix the described problem - it fixes a similar issue which causes a premature crash for my reduced testcase.

NDEBUG would migrate it - but I'm currently developing with debug builds and it's becoming rather annoying... so - I tracked down the actual bug in iTaSC itself:

If the last added segment is a None joint (no DoF) q_nr will reference a non-existing element in the joint array - TreeFkSolverPos_recursive::recursiveFk will reference that non-existing joint:

		Frame currentFrame = currentElement.segment.pose(((JntArray&)q_in)(currentElement.q_nr));

... and pass the value to KDL::Segment::pose() which will then ignore the passed value in case of a None joint.

Note that my original comment was wrong - there is no actual memory access happening... but if you hope to some day get rid of the iTaSC crashes (there are quite some - also with NDEBUG builds) you need to be able to run it with assertions enabled...

I'm not going to talk about iTaSC's very questionable API passing pointers to possibly never-referenced values (or maybe more than 1, depending on the joint type) as references to the first element here... this results in some (IMHO) very fragile code in Blender's itasc_plugin.cpp with all the DoF counting...

I'm not sure how this should be fixed properly... the iTaSC API really should be repaired, but you could work around the issue by always having an additional dummy value in the joint array at the end... That is, unless you accept that iTaSC must never be used with assertions enabled?

I suppose one should possibly report an upstream bug for this but I have no idea how the relation between Blender and the iTaSC project is, so I'll wait for some feedback on this report.

In case you consider this to be a non-issue - sorry for the noise...

%%%

**Relates to**: #31430 %%%I'm resubmitting this as a bug related to #31430 because I don't see a way to reopen my own bug report... The attached patch to #31430 (which was committed according to the comments) does _not_ fix the described problem - it fixes a similar issue which causes a premature crash for my reduced testcase. NDEBUG would migrate it - but I'm currently developing with debug builds and it's becoming rather annoying... so - I tracked down the actual bug in iTaSC itself: If the last added segment is a None joint (no DoF) q_nr will reference a non-existing element in the joint array - TreeFkSolverPos_recursive::recursiveFk will reference that non-existing joint: Frame currentFrame = currentElement.segment.pose(((JntArray&)q_in)(currentElement.q_nr)); ... and pass the value to KDL::Segment::pose() which will then ignore the passed value in case of a None joint. Note that my original comment was wrong - there is no actual memory access happening... but if you hope to some day get rid of the iTaSC crashes (there are quite some - also with NDEBUG builds) you need to be able to run it with assertions enabled... I'm not going to talk about iTaSC's very questionable API passing pointers to possibly never-referenced values (or maybe more than 1, depending on the joint type) as references to the first element here... this results in some (IMHO) very fragile code in Blender's itasc_plugin.cpp with all the DoF counting... I'm not sure how this should be fixed properly... the iTaSC API really should be repaired, but you could work around the issue by always having an additional dummy value in the joint array at the end... That is, unless you accept that iTaSC must never be used with assertions enabled? I suppose one should possibly report an upstream bug for this but I have no idea how the relation between Blender and the iTaSC project is, so I'll wait for some feedback on this report. In case you consider this to be a non-issue - sorry for the noise... %%%

Changed status to: 'Open'

Changed status to: 'Open'
Member

%%%Thanks for the report. I fixed the bug in revision 47438. Note that your test case is a very special one: the armature has no joint at all since all 3 axis are locked.

Regarding the strange way of passing pointer, I totally agree with your comment. The reason I did this is because this part of iTaSC is in fact a separate library called KDL that didn't support nDoF joints. Adding proper support for nDoF joints in KDL would have required a significant redesign of the library, which was not in the scope of my project. I left this to the maintainers of the library, but never got to the bottom of it. I don't even know if it was ever fixed in the original library.

Nevertheless, the trick I'm using in iTaSC is safe provided that the joint exist, which is now guarantee by the patch.

%%%

%%%Thanks for the report. I fixed the bug in revision 47438. Note that your test case is a very special one: the armature has no joint at all since all 3 axis are locked. Regarding the strange way of passing pointer, I totally agree with your comment. The reason I did this is because this part of iTaSC is in fact a separate library called KDL that didn't support nDoF joints. Adding proper support for nDoF joints in KDL would have required a significant redesign of the library, which was not in the scope of my project. I left this to the maintainers of the library, but never got to the bottom of it. I don't even know if it was ever fixed in the original library. Nevertheless, the trick I'm using in iTaSC is safe provided that the joint exist, which is now guarantee by the patch. %%%
Member

Changed status from 'Open' to: 'Archived'

Changed status from 'Open' to: 'Archived'
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#31544
No description provided.