Yarp: Problem with move semantic in yarp::sig::Vector

Created on 31 Jan 2020  路  4Comments  路  Source: robotology/yarp

With the latest devel branch, running the wholeBodyDynamics on iCubGenova01 with --autoconnect --no_legs --headV2 results in a crash in the following block:
https://github.com/robotology/icub-main/blob/b0c29f7890b82df3ae96759debf26c8246c8dbba/src/modules/wholeBodyDynamics/observerThread.cpp#L780-L803

tested with @xEnVrE @randaz81

Library - YARP_sig YARP v3.4.0 Bug Fixed

All 4 comments

Digging into it I found out that it is not robot-related, I suspect that the cause is the introduction of move semantics in yarp::sig::Vector.

I suspect it because I had a old yarp on my pc and it was not crashing, after updating yarp it crashed also on my pc.

Running it with gdb I have this output:

image

The strange thing is that the segmentation fault happens at this line:

char* buf = new char[len];

wher len is !=0.

Running wholeBodyDynamics with the latest yarp master with Valgrind I have:

==11076== 
==11076== HEAP SUMMARY:
==11076==     in use at exit: 289 bytes in 2 blocks
==11076==   total heap usage: 2,111,778 allocs, 2,111,776 frees, 156,247,902 bytes allocated
==11076== 
==11076== LEAK SUMMARY:
==11076==    definitely lost: 0 bytes in 0 blocks
==11076==    indirectly lost: 0 bytes in 0 blocks
==11076==      possibly lost: 0 bytes in 0 blocks
==11076==    still reachable: 289 bytes in 2 blocks
==11076==         suppressed: 0 bytes in 0 blocks
==11076== Rerun with --leak-check=full to see details of leaked memory
==11076== 
==11076== For counts of detected and suppressed errors, rerun with: -v
==11076== Use --track-origins=yes to see where uninitialised values come from
==11076== ERROR SUMMARY: 1707 errors from 11 contexts (suppressed: 0 from 0)

It doesn't crash, probably because valgrind slows it down a lot.

Adding --leak-check=full we have some:

==21062== Conditional jump or move depends on uninitialised value(s)
==21062==    at 0x1A4F6E: iCub::skinDynLib::dynContact::checkVectorDim(yarp::sig::VectorOf<double> const&, unsigned int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (dynContact.cpp:283)
==21062==    by 0x1A40C5: iCub::skinDynLib::dynContact::setForceMoment(yarp::sig::VectorOf<double> const&) (dynContact.cpp:145)
==21062==    by 0x1318E1: inverseDynamics::run() (observerThread.cpp:794)
==21062==    by 0x59D93A8: yarp::os::PeriodicThread::Private::step() (PeriodicThread.cpp:183)
==21062==    by 0x59D9917: yarp::os::PeriodicThread::Private::run() (PeriodicThread.cpp:210)
==21062==    by 0x5A93E40: theExecutiveBranch(void*) (ThreadImpl.cpp:80)
==21062==    by 0x5A95761: void std::__invoke_impl<void, void (*)(void*), void*>(std::__invoke_other, void (*&&)(void*), void*&&) (invoke.h:60)
==21062==    by 0x5A956B1: std::__invoke_result<void (*)(void*), void*>::type std::__invoke<void (*)(void*), void*>(void (*&&)(void*), void*&&) (invoke.h:95)
==21062==    by 0x5A95671: _ZNSt6thread8_InvokerISt5tupleIJPFvPvES2_EEE9_M_invokeIJLm0ELm1EEEEDTclsr3stdE8__invokespcl10_S_declvalIXT_EEEEESt12_Index_tupleIJXspT_EEE (thread:234)
==21062==    by 0x5A95624: std::thread::_Invoker<std::tuple<void (*)(void*), void*> >::operator()() (thread:243)
==21062==    by 0x5A953E8: std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)(void*), void*> > >::_M_run() (thread:186)
==21062==    by 0x61606EE: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25)

Similar issue: https://github.com/robotology/yarp/issues/2189

Reverting the commit that add yarp::sig::Vector move semantics(https://github.com/robotology/yarp/commit/23dbd2849c090dcf12894156c6d953373ef75ee5) it doesn't crash both with and without valgrind and I have this output:

==16126== 
==16126== HEAP SUMMARY:
==16126==     in use at exit: 289 bytes in 2 blocks
==16126==   total heap usage: 2,376,095 allocs, 2,376,093 frees, 177,525,007 bytes allocated
==16126== 
==16126== LEAK SUMMARY:
==16126==    definitely lost: 0 bytes in 0 blocks
==16126==    indirectly lost: 0 bytes in 0 blocks
==16126==      possibly lost: 0 bytes in 0 blocks
==16126==    still reachable: 289 bytes in 2 blocks
==16126==         suppressed: 0 bytes in 0 blocks
==16126== Rerun with --leak-check=full to see details of leaked memory
==16126== 
==16126== For counts of detected and suppressed errors, rerun with: -v
==16126== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Unless we will fix this up soonish, I recommend that we roll back this modification in yarp/master.
Moreover, we could grab the opportunity to use smart pointers underneath to avoid manual disposal of the allocated memory.

cc @drdanz

Was this page helpful?
0 / 5 - 0 ratings