telemetryDeviceDumper: segmentation fault when trying to save data

[Nicogene]

After #108 I managed to run with the gazebo icub simulator and I get this segmentation fault when it tried to save the files:

[ERROR] yarprobotinterface intercepted a segmentation fault caused by a faulty plugin:
[ERROR] /lib/x86_64-linux-gnu/libc.so.6(+0x18e964) [0x7f2ccb5ab964]
Trace requested at /home/ngenesio/robotology/robotology-superbuild/robotology/YARP/src/yarprobotinterface/Module.cpp:90 by code called from:
/home/ngenesio/robotology/robotology-superbuild/build/install/lib/libYARP_os.so.3(_Z16yarp_print_traceP8_IO_FILEPKcj+0x3b) [0x7f2ccb8da39b]
yarprobotinterface(+0x76a6) [0x55648f13c6a6]
/lib/x86_64-linux-gnu/libc.so.6(+0x46210) [0x7f2ccb463210]
/lib/x86_64-linux-gnu/libc.so.6(+0x18e964) [0x7f2ccb5ab964]
/usr/lib/x86_64-linux-gnu/libmatio.so.9(Mat_VarCreate+0x4db) [0x7f2cb06cf09b]
/home/ngenesio/robotology/robotology-superbuild/build/install/lib/libmatioCpp.so.0.1.0(_ZN8matioCpp8Variable18initializeVariableERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS_12VariableTypeERKNS_9ValueTypeENS_4SpanIKmLln1EEEPv+0x167) [0x7f2cb
072d127]
/home/ngenesio/robotology/robotology-superbuild/build/install/lib/yarp/yarp_telemetryDeviceDumper.so(_ZN4yarp9telemetry13BufferManagerIdE10saveToFileEb+0x592) [0x7f2cb0783fc2]
/home/ngenesio/robotology/robotology-superbuild/build/install/lib/yarp/yarp_telemetryDeviceDumper.so(_ZN4yarp9telemetry13BufferManagerIdE12periodicSaveEv+0x1a2) [0x7f2cb07851a2]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xd6d84) [0x7f2ccb702d84]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x9609) [0x7f2ccb17c609]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f2ccb53f293]
[DEBUG] yarprobotinterface running happily
Illegal instruction

This bug has been introduced by the recent changes( #103 #104 #105 #106)

It is under investigation

[Nicogene]

Here is the bt:

[Switching to Thread 0x7fff67fff700 (LWP 11001)]
__memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:384
384     ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory.
(gdb) bt
#0  __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:384
#1  0x00007ffff435709b in Mat_VarCreate () from /usr/lib/x86_64-linux-gnu/libmatio.so.9
#2  0x00007ffff439a127 in matioCpp::Variable::initializeVariable(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, matioCpp::VariableType const&, matioCpp::ValueType const&, matioCpp::Span<unsigned long const, -1l>, void*) ()
   from /home/ngenesio/robotology/robotology-superbuild/build/install/lib/libmatioCpp.so.0.1.0
#3  0x00007ffff44e398c in matioCpp::MultiDimensionalArray<double>::MultiDimensionalArray (this=0x7fff67ffeb00, name="data",
    dimensions=std::vector of length 3, capacity 3 = {...}, inputVector=0x7fff5c00b270)
    at /home/ngenesio/robotology/robotology-superbuild/build/install/include/matioCpp/impl/MultiDimensionalArray.tpp:102
#4  0x00007ffff44df944 in yarp::telemetry::BufferManager<double>::saveToFile (this=0x5555557464a0, flush_all=false)
    at /home/ngenesio/robotology/yarp-telemetry/src/libYARP_telemetry/src/yarp/telemetry/BufferManager.h:331
#5  0x00007ffff44e626d in yarp::telemetry::BufferManager<double>::periodicSave (this=0x5555557464a0)
    at /home/ngenesio/robotology/yarp-telemetry/src/libYARP_telemetry/src/yarp/telemetry/BufferManager.h:396
#6  0x00007ffff44f4c6a in std::__invoke_impl<void, void (yarp::telemetry::BufferManager<double>::*)(), yarp::telemetry::BufferManager<double>*> (
    __f=@0x555555752fc0: (void (yarp::telemetry::BufferManager<double>::*)(yarp::telemetry::BufferManager<double> * const)) 0x7ffff44e61cc <yarp::telemetry::BufferManager<double>::periodicSave()>, __t=@0x555555752fb8: 0x5555557464a0)
    at /usr/include/c++/9/bits/invoke.h:73
#7  0x00007ffff44f4b98 in std::__invoke<void (yarp::telemetry::BufferManager<double>::*)(), yarp::telemetry::BufferManager<double>*>
    (
    __fn=@0x555555752fc0: (void (yarp::telemetry::BufferManager<double>::*)(yarp::telemetry::BufferManager<double> * const)) 0x7ffff44e61cc <yarp::telemetry::BufferManager<double>::periodicSave()>) at /usr/include/c++/9/bits/invoke.h:95
#8  0x00007ffff44f4acb in std::thread::_Invoker<std::tuple<void (yarp::telemetry::BufferManager<double>::*)(), yarp::telemetry::BufferManager<double>*> >::_M_invoke<0ul, 1ul> (this=0x555555752fb8) at /usr/include/c++/9/thread:244
#9  0x00007ffff44f4850 in std::thread::_Invoker<std::tuple<void (yarp::telemetry::BufferManager<double>::*)(), yarp::telemetry::BufferManager<double>*> >::operator() (this=0x555555752fb8) at /usr/include/c++/9/thread:251
#10 0x00007ffff44f3b3e in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (yarp::telemetry::BufferManager<double>::*)(), yarp::telemetry::BufferManager<double>*> > >::_M_run (this=0x555555752fb0) at /usr/include/c++/9/thread:195
#11 0x00007ffff7c75d84 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#12 0x00007ffff76ef609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#13 0x00007ffff7ab2293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

[S-Dafarra]

Can you add the check on the size of linearMatrix as suggested in #107 (comment)? I suspect the problem is in the size of the input vector.

[Nicogene]

Debugging I got this:

buffInfo.m_buffer.size() 100000
buffInfo.m_buffer.capacity() 100000
I am creating the MDA
linear_matrix.size() 3136
timestamp_vector.size() 100000
dimensions 32 1

In particular It surprised me that buffInfo.m_buffer.size() is 100000 even if we the amount of data pushed is for sure less(I put the save_period to 1s)

[S-Dafarra]

Debugging I got this:

buffInfo.m_buffer.size() 100000
buffInfo.m_buffer.capacity() 100000
I am creating the MDA
linear_matrix.size() 3136
timestamp_vector.size() 100000
dimensions 32 1

In particular It surprised me that buffInfo.m_buffer.size() is 100000 even if we the amount of data pushed is for sure less(I put the save_period to 1s)

Note that linearMatrix.size() should be 32 * 1 * 100000, that does not seem the case.

[Nicogene]

Note that linearMatrix.size() should be 32 * 1 * 100000, that does not seem the case.

Yeah, buffer.size() should be 98, not 100000, I will check if also before the changes there was this issue

[Nicogene]

The strange thing is that on WSL I am getting the very same error also if I roll back to the first version of device #89

If I put a small value for n_sample (e.g. 10), then we are sure that the buffer is full, everything works fine.

Probably I didn't understand how boost::circular_buffer works, I expected that the size() changes when you push elements inside.

[Nicogene]

With the latest version putting n_sample I manage to save data:

-rw-r--r--  1 ngenesio ngenesio   655 Mar 25 17:24 bufferConfigtest_telemetry.json
-rw-r--r--  1 ngenesio ngenesio 12136 Mar 25 17:24 test_telemetry_1616689468.116592.mat
-rw-r--r--  1 ngenesio ngenesio 12136 Mar 25 17:24 test_telemetry_1616689469.117558.mat
-rw-r--r--  1 ngenesio ngenesio 12136 Mar 25 17:24 test_telemetry_1616689470.118642.mat
-rw-r--r--  1 ngenesio ngenesio 12136 Mar 25 17:24 test_telemetry_1616689471.119802.mat
-rw-r--r--  1 ngenesio ngenesio 12136 Mar 25 17:24 test_telemetry_1616689472.120528.mat
-rw-r--r--  1 ngenesio ngenesio 12136 Mar 25 17:24 test_telemetry_1616689473.121351.mat
-rw-r--r--  1 ngenesio ngenesio  5800 Mar 25 17:24 test_telemetry_1616689473.144277.mat

Checking the documentation actually resize() change both size and capacity, reserve does not seem to do what it does usually in stl containers and probably what we need is set_capacity

[Nicogene]

This bug probably explains also why some .mat were corrupted (see #107) or had number of timestamps ~= num of samples