pinocchio.Data(model) fails with -march=native

[cmastalli]

Hi all,

I have spent a couple of hours understanding what it is going, however, I have to admit that I don't have any clue. I have compiled Pinocchio with march=native flag, without support of Codegen and Collision to narrow down the issue, and this is the problem:

import pinocchio

model = pinocchio.buildSampleModelHumanoid()
for i in range(100): # I used a for-loop because sometime doesn't fail in the first call
  data = pinocchio.Data(model) # This produces an error
  #data = pinocchio.Model.createData(model) # Instead this works, WHY?

Additionally, this is the detailed information error generated by gdb:

python: /usr/local/include/eigen3/Eigen/src/Core/DenseStorage.h:128: Eigen::internal::plain_array<T, Size, MatrixOrArrayOptions, 32>::plain_array() [with T = double; int Size = 36; int MatrixOrArrayOptions = 0]: Assertion `(internal::UIntPtr(eigen_unaligned_array_assert_workaround_gcc47(array)) & (31)) == 0 && "this assertion is explained here: " "http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html" " **** READ THIS WEB PAGE !!! ****"' failed.

Thread 1 "python" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007ffff7a24801 in __GI_abort () at abort.c:79
#2  0x00007ffff7a1439a in __assert_fail_base (fmt=0x7ffff7b9b7d8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
    assertion=assertion@entry=0x7fffcacef920 "(internal::UIntPtr(eigen_unaligned_array_assert_workaround_gcc47(array)) & (31)) == 0 && \"this assertion is explained here: \" \"http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.htm"..., file=file@entry=0x7fffcacee9f8 "/usr/local/include/eigen3/Eigen/src/Core/DenseStorage.h", line=line@entry=128, 
    function=function@entry=0x7fffcacf7160 <Eigen::internal::plain_array<double, 36, 0, 32>::plain_array()::__PRETTY_FUNCTION__> "Eigen::internal::plain_array<T, Size, MatrixOrArrayOptions, 32>::plain_array() [with T = double; int Size = 36; int MatrixOrArrayOptions = 0]") at assert.c:92
#3  0x00007ffff7a14412 in __GI___assert_fail (
    assertion=0x7fffcacef920 "(internal::UIntPtr(eigen_unaligned_array_assert_workaround_gcc47(array)) & (31)) == 0 && \"this assertion is explained here: \" \"http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.htm"..., file=0x7fffcacee9f8 "/usr/local/include/eigen3/Eigen/src/Core/DenseStorage.h", line=128, 
    function=0x7fffcacf7160 <Eigen::internal::plain_array<double, 36, 0, 32>::plain_array()::__PRETTY_FUNCTION__> "Eigen::internal::plain_array<T, Size, MatrixOrArrayOptions, 32>::plain_array() [with T = double; int Size = 36; int MatrixOrArrayOptions = 0]") at assert.c:101
#4  0x00007fffc9ee8771 in Eigen::internal::plain_array<double, 36, 0, 32>::plain_array (this=0x5555561eb730) at /usr/local/include/eigen3/Eigen/src/Core/DenseStorage.h:128
#5  0x00007fffc9ed5bec in Eigen::DenseStorage<double, 36, 6, 6, 0>::DenseStorage (this=0x5555561eb730) at /usr/local/include/eigen3/Eigen/src/Core/DenseStorage.h:187
#6  0x00007fffc9ec310a in Eigen::PlainObjectBase<Eigen::Matrix<double, 6, 6, 0, 6, 6> >::PlainObjectBase (this=0x5555561eb730) at /usr/local/include/eigen3/Eigen/src/Core/PlainObjectBase.h:484
#7  0x00007fffc9ead944 in Eigen::Matrix<double, 6, 6, 0, 6, 6>::Matrix (this=0x5555561eb730) at /usr/local/include/eigen3/Eigen/src/Core/Matrix.h:259
#8  0x00007fffca5ef9dd in pinocchio::DataTpl<double, 0, pinocchio::JointCollectionDefaultTpl>::DataTpl (this=0x5555561eb450, model=...)
    at /home/cmastalli/devel/pinocchio/build_debug/include/pinocchio/multibody/data.hxx:108
#9  0x00007fffca5eb391 in boost::python::objects::value_holder<pinocchio::DataTpl<double, 0, pinocchio::JointCollectionDefaultTpl> >::value_holder<boost::python::objects::reference_to_value<pinocchio::ModelTpl<double, 0, pinocchio::JointCollectionDefaultTpl> > > (this=0x5555561eb430, self=0x7fffc3af01d0, a0=...) at /usr/include/boost/python/object/value_holder.hpp:133
#10 0x00007fffca5e7711 in boost::python::objects::make_holder<1>::apply<boost::python::objects::value_holder<pinocchio::DataTpl<double, 0, pinocchio::JointCollectionDefaultTpl> >, boost::mpl::vector1<pinocchio::ModelTpl<double, 0, pinocchio::JointCollectionDefaultTpl> > >::execute (p=0x7fffc3af01d0, a0=...) at /usr/include/boost/python/object/make_holder.hpp:94
#11 0x00007fffca7e469c in boost::python::detail::invoke<int, void (*)(_object*, pinocchio::ModelTpl<double, 0, pinocchio::JointCollectionDefaultTpl>), boost::python::arg_from_python<_object*>, boost::python::arg_from_python<pinocchio::ModelTpl<double, 0, pinocchio::JointCollectionDefaultTpl> > > (
    f=@0x5555560d8868: 0x7fffca5e7694 <boost::python::objects::make_holder<1>::apply<boost::python::objects::value_holder<pinocchio::DataTpl<double, 0, pinocchio::JointCollectionDefaultTpl> >, boost::mpl::vector1<pinocchio::ModelTpl<double, 0, pinocchio::JointCollectionDefaultTpl> > >::execute(_object*, pinocchio::ModelTpl<double, 0, pinocchio::JointCollectionDefaultTpl>)>, ac0=..., ac1=...)
    at /usr/include/boost/python/detail/invoke.hpp:79
#12 0x00007fffca7d9fc5 in boost::python::detail::caller_arity<2u>::impl<void (*)(_object*, pinocchio::ModelTpl<double, 0, pinocchio::JointCollectionDefaultTpl>), boost::python::default_call_policies, boost::mpl::vector3<void, _object*, pinocchio::ModelTpl<double, 0, pinocchio::JointCollectionDefaultTpl> > >::operator() (this=0x5555560d8868, args_=0x7ffff7efddc0)
    at /usr/include/boost/python/detail/caller.hpp:216
#13 0x00007fffca7d007d in boost::python::objects::caller_py_function_impl<boost::python::detail::caller<void (*)(_object*, pinocchio::ModelTpl<double, 0, pinocchio::JointCollectionDefaultTpl>), boost::python::default_call_policies, boost::mpl::vector3<void, _object*, pinocchio::ModelTpl<double, 0, pinocchio::JointCollectionDefaultTpl> > > >::operator() (this=0x5555560d8860, args=0x7ffff7efddc0, kw=0x0)
    at /usr/include/boost/python/object/py_function.hpp:38
#14 0x00007fffc529fe55 in boost::python::objects::function::call(_object*, _object*) const () from /usr/lib/x86_64-linux-gnu/libboost_python-py27.so.1.65.1
#15 0x00007fffc52a0008 in ?? () from /usr/lib/x86_64-linux-gnu/libboost_python-py27.so.1.65.1
#16 0x00007fffc52a6bcb in boost::python::detail::exception_handler::operator()(boost::function0<void> const&) const () from /usr/lib/x86_64-linux-gnu/libboost_python-py27.so.1.65.1
#17 0x00007fffc57386d3 in boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<eigenpy::Exception, void (*)(eigenpy::Exception const&)>, boost::_bi::list3<boost::arg<1>, boost::arg<2>, boost::_bi::value<void (*)(eigenpy::Exception const&)> > >, bool, boost::python::detail::exception_handler const&, boost::function0<void> const&>::invoke(boost::detail::function::function_buffer&, boost::python::detail::exception_handler const&, boost::function0<void> const&) () from /usr/local/lib/libeigenpy.so
#18 0x00007fffc52a696f in boost::python::handle_exception_impl(boost::function0<void>) () from /usr/lib/x86_64-linux-gnu/libboost_python-py27.so.1.65.1
#19 0x00007fffc529d6c9 in ?? () from /usr/lib/x86_64-linux-gnu/libboost_python-py27.so.1.65.1
#20 0x000055555567a70e in ?? ()
#21 0x000055555567a33a in ?? ()
#22 0x00005555556370ab in ?? ()
#23 0x000055555564db20 in PyEval_EvalFrameEx ()
#24 0x00005555556462aa in PyEval_EvalCodeEx ()
#25 0x0000555555645d19 in PyEval_EvalCode ()
#26 0x000055555567694f in ?? ()
#27 0x0000555555671be2 in PyRun_FileExFlags ()
#28 0x000055555567160d in PyRun_SimpleFileExFlags ()
#29 0x0000555555620356 in Py_Main ()
#30 0x00007ffff7a05b97 in __libc_start_main (main=0x55555561fd30 <main>, argc=2, argv=0x7fffffffda98, init=<optimised out>, fini=<optimised out>, rtld_fini=<optimised out>, stack_end=0x7fffffffda88)
    at ../csu/libc-start.c:310
#31 0x000055555561fc4a in _start ()

I inspected the pinocchio::Data structure looking for possible issue regarding data alignment, and IMHO everything looks OK. I wonder if this is related to the bindings of the copy constructor function.

Carlos

[jcarpent]

It will be hard to debug your case if you did not provide the compilation flags you're using to compile EigenPy and Pinocchio. In addition, you should provide the current version of Eigen you're using. If you are still on the master branch of Eigen (according to the output you provided, this is the case), I prefer to avoid debugging it. Please use a release version instead.

[cmastalli]

It will be hard to debug your case if you did not provide the compilation flags you're using to compile EigenPy and Pinocchio.

I compiled both in Release mode with -march=native, nothing else.

In addition, you should provide the current version of Eigen you're using

I am using Eigen 3.3.7.

As a side comment -- there are other issues in the Eigen master but I abandoned this since it is not stable neither priority.

[jmirabel]

Do you have the same behavior in C++ ?

[jcarpent]

It is weird, because in Release mode you should not see any of the assert.

[jmirabel]

I guess it is in debug mode: /home/cmastalli/devel/pinocchio/build_debug/include/pinocchio/multibody/data.hxx

[cmastalli]

It is weird, because in Release mode you should not see any of the assert.

Sorry, I meant that I encountered the issue with Release mode. Then I debugged with gdb, and of course switched to Debug mode (only in Pinocchio).

I think the question could be: should I install eigenpy in Debug mode as well?

[cmastalli]

Do you have the same behavior in C++ ?

I didn't try in c++.

[jmirabel]

It would help understanding whether the issue is at the bindings level or at the core level. Could you to it ?

[jcarpent]

The issue is coming from Python in fact. At the Boost level, we have to mention that Model has to be realigned thanks to some template specialization provided by EigenPy.

[jmirabel]

@jcarpent at the moment, is there a way to list known bugs that will not be fixed, as this one ?

[jcarpent]

Not really. The memory is currently stored in the issues.

[wxmerkt]

Perhaps let's add a label "known-bug-wont-fix". That way it can easily be filtered