Add unittest for costModelResidualPairCollision

[edantec]

Proper rebase of the unittest for pair collision

[proyan]

@edantec The unittests are segfaulting. Please check where this segfault is coming from.

[wxmerkt]

The test also needs checking for whether Pinocchio is built with HPP-FCL

[nim65s]

Running 50 test cases...
*** No errors detected
malloc_consolidate(): invalid chunk size

This segfault is not coming from the code or the test, but after the tests. We have this kind of issues everywhere, ref eg. https://gitlab.laas.fr/loco-3d/crocoddyl/-/issues/288. So either we have no idea how to properly code in C++ and we are handling pointers in a bad way leading to possible double free or something like that ; or the segfault just come from Boost::unit_test_framework.

It usually hit on Arch and Debian (CI on Debian is most of the time ignored because of that), but rarely on Ubuntu, no matter which versions.

I was sometimes able to workaround that by splitting the failing tests in two different unit tests, and with exactly the same code, but not at the same place, the issue disappeared.

[edantec]

I confirm that on my side, my tests are not segfaulting, and I'm working with Ubuntu

[nim65s]

eg. on Debian 9, with

set (CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -fno-omit-frame-pointer -fsanitize=address")
set (CMAKE_LINKER_FLAGS_DEBUG "${CMAKE_LINKER_FLAGS_DEBUG} -fno-omit-frame-pointer -fsanitize=address")

root@0ea005377d08:~/crocoddyl/build# ./unittest/test_states 
Running test_StateVector
Running test_StateMultibody_TalosArm
Running test_StateMultibody_HyQ
Running test_StateMultibody_Talos
Running test_StateMultibody_RandomHumanoid
Running 60 test cases...

*** No errors detected
=================================================================
==6337==ERROR: AddressSanitizer: attempting double-free on 0x60300000ea40 in thread T0:
    #0 0x7f273cbc71f0 in operator delete(void*) (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc31f0)
    #1 0x7f27325fccae in __cxa_finalize (/lib/x86_64-linux-gnu/libc.so.6+0x35cae)
    #2 0x7f2737efc182  (/usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.62.0+0x3f182)

0x60300000ea40 is located 0 bytes inside of 18-byte region [0x60300000ea40,0x60300000ea52)
freed by thread T0 here:
    #0 0x7f273cbc71f0 in operator delete(void*) (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc31f0)
    #1 0x7f27325fc93f  (/lib/x86_64-linux-gnu/libc.so.6+0x3593f)

previously allocated by thread T0 here:
    #0 0x7f273cbc6bf0 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc2bf0)
    #1 0x55ef126da18c in void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) /usr/include/c++/6/bits/basic_string.tcc:219
    #2 0x7f2732fa13cb in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x1203cb)

SUMMARY: AddressSanitizer: double-free (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc31f0) in operator delete(void*)
==6337==ABORTING

I don't see a single thing from our codebase in this backtrace. This doesn't mean that the bug is not from our side, but as I can't reproduce this on Ubuntu… I'm really wondering if this is worth it to investigate more, or just live with it, or even try the same test in another unit test framework.

[cmastalli]

I'm really wondering if this is worth it to investigate more, or just live with it, or even try the same test in another unit test framework.

I think we should investigate it. I also spent (quite time ago) a bit of my time, but unfortunately, I have no clue and little bandwidth for it.

If this task requires time (which I believe so) and everyone agree, then we could decide to allow failures in Buster.

[proyan]

If this is related to #964 , it may be reproduced by using clang as the compiler. Could you try it @edantec ?

[nim65s]

I tried: using clang 8 on 18.04, with or without ASan, doesn't trigger the issue.

[edantec]

What is the current state of this PR? How can I help to pass it?

[proyan]

@edantec I don't think you have anything to do immediately. This is a issue that we need to investigate first. What I can propose is that we leave this open for now, and I'll investigate this in the next week.

[cmastalli]

@edantec -- could you rebase this branch?
There are some changes in the unittests that might be beneficial for this PR.

[cmastalli]

@edantec -- I have rebased this branch.
Let's see if the jobs pass after merging #1053

[cmastalli]

@wxmerkt -- it seems to me that we are not install Pinocchio with hpp-fcl.
Is that right? or what is the reason of the ROS-CI failures?
If so, how feasible is to do it soon?

[wxmerkt]

@wxmerkt -- it seems to me that we are not install Pinocchio with hpp-fcl.
Is that right? or what is the reason of the ROS-CI failures?
If so, how feasible is to do it soon?

Correct, the ROS-Pinocchio-binary does not compile with HPP-FCL right now. I can make a HPP-FCL release soon - it would take a few weeks to become available though.

In either case, we should guard the code with the #ifdef PINOCCHIO_WITH_HPP_FCL_SUPPORT macro so that it doesn't fail on CI.

[cmastalli]

Correct, the ROS-Pinocchio-binary does not compile with HPP-FCL right now. I can make a HPP-FCL release soon - it would take a few weeks to become available though.

It would be useful to release and integrate such kind of binaries and CI.
I have included this topic here: #1027

In either case, we should guard the code with the #ifdef PINOCCHIO_WITH_HPP_FCL_SUPPORT macro so that it doesn't fail on CI.

I agree. I've disabled the compilation of these unit-tests.

[cmastalli]

@edantec -- I have made all the modifications needed to merge this PR.
I will merge it as soon as all the jobs pass.