ros2 / rmw_implementation Goto Github PK

This issue tracks the progression of rmw_implementation to Quality Level 1 and a 1.0 version level. It follows the outline described in REP 2004.

1 Version Policy:

• 1.i Must have a version policy (e.g. semver)
• 1.ii Must be at a stable version (e.g. for semver that means version >= 1.0.0)
• 1.iii Must have a strictly declared public API - N/A
• 1.iv Must have a policy for API stability
• 1.v Must have a policy for ABI stability
• 1.vi Must have a policy that keeps API and ABI stability within a released ROS distribution

2 Change Control Process:

• 2.i Must have all code changes occur through a change request (e.g. pull request, merge request, etc.)
• 2.ii Must have confirmation of contributor origin (e.g. DCO, CLA, etc.)
• 2.iii Must have peer review policy for all change requests (e.g. require one or more reviewers)
• 2.iv Must have Continuous Integration (CI) policy for all change requests
• 2.v Must have documentation policy for all change requests

3 Documentation:

• 3.i Must have documentation for each "feature" (e.g. for rclcpp: create a node, publish a message, spin, etc.) N/A
• 3.ii Must have documentation for each item in the public API (e.g. functions, classes, etc.) N/A
• 3.iii Must have a declared license or set of licenses
• 3.iv Must state copyrights within the project and attribute all authors
• 3.v Must have a "quality declaration" document, which declares the quality level and justifies how the package meets each of the requirements
  • 3.v.a Must have a section in the repository's README which contains the "quality declaration" or links to it
  • [v] 3.v.b Should register with a centralized list of 'Level N' packages, if one exists, to allow for peer review of the claim (counting REP-2005 as such list)
  • 3.v.c Must reference any 'Level N' lists the package belongs to, and/or any other peer review processes undergone

4 Testing:

• 4.i Must have system tests which cover all items in the "feature" documentation

• 4.ii Must have system, integration, and/or unit tests which cover all of the public API

• 4.iii Code Coverage:

  • 4.iii.a Must have code coverage tracking for the package
  • 4.iii.b Must have and enforce a code coverage policy for new changes
  • not required but stating something like "above 95%" as a minimum would be good too (to match developer guide)

• 4.iv Performance:

  • 4.iv.a Must have performance tests (exceptions allowed if they don't make sense to have) N/A
  • 4.iv.b Must have a performance regression policy (i.e. blocking either changes or releases on unexpected performance regressions)

• 4.v Linters and Static Analysis:

  • 4.v.a Must have a code style and enforce it
  • 4.v.b Must use static analysis tools where applicable

5 Dependencies:

• Must not have direct runtime "ROS" dependencies which are not at the same level as the package in question ('Level N'), but...
• May have optional direct runtime "ROS" dependencies which are not 'Level N', e.g. tracing or debugging features that can be disabled
• Must have justification for why each direct runtime "non-ROS" dependency is equivalent to a 'Level N' package in terms of quality

6 Platform Support:

• Must support all target platforms for the package's ecosystem.
  For ROS 2 this means supporting all tier 1 platforms, as defined in REP-2000

7 Security

• Must have a declared Vulnerability Disclosure Policy and adhere to a response schedule for addressing security vulnerabilities

It looks like the get_library function creates a pointer to a SharedLibrary object on the heap, which never gets cleaned up. This should probably be handled better and maybe wrapped in a unique_ptr to make the object lifecycle more obvious.

Hi,
I'm trying to build rmw_implementation but I constantly get the following error:

CMake Error at some/path/install/rmw_implementation_cmake/share/rmw_implementation_cmake/cmake/get_default_rmw_implementation.cmake:60 (message):
  Could not find ROS middleware implementation 'NOTFOUND'.  Choose one of the
  following:
Call Stack (most recent call first):
  CMakeLists.txt:22 (get_default_rmw_implementation)

I did install fastrtps through the ubuntu repo.

sudo apt install libfastrtps-dev

Even if it sounds not really consistent, I can find .cmake files under /usr/local/share/etc... but the get_default_rmw_implementation macro still doesn't find it (even if it is the default one).

Bug report

Required Info:

• Operating System:
  • Ubuntu 22.04
• Installation type:
  • From source with colcon
• Version or commit hash:
  • humble branch (413eb31)
• DDS implementation:
  • Fast-RTPS
• Client library (if applicable):
  • targetting rclcpp but rmw_implementation is a requirement of rcl on which rclcpp also depends

Steps to reproduce issue

In a clean directory, clone all the following repo:

git clone -b humble https://github.com/ros2/ament_cmake_ros.git
git clone -b humble https://github.com/ros2/rosidl_defaults.git
git clone -b humble https://github.com/ros2/rosidl_dds.git
git clone -b humble https://github.com/osrf/osrf_testing_tools_cpp.git
git clone -b humble https://github.com/ros2/performance_test_fixture.git
git clone -b humble https://github.com/ros2/python_cmake_module.git
git clone -b humble https://github.com/ros2/launch.git
git clone -b humble https://github.com/ros2/mimick_vendor.git
git clone -b humble https://github.com/ros2/rcutils.git
git clone -b humble https://github.com/ros2/test_interface_files.git
git clone -b humble https://github.com/ros2/rcpputils.git
git clone -b humble https://github.com/ros2/unique_identifier_msgs.git
git clone -b humble https://github.com/ros2/rosidl.git
git clone -b humble https://github.com/ros2/rosidl_typesupport.git
colcon build
source ./intsall/setup.bash
git clone -b humble https://github.com/ament/ament_index.git
git clone -b humble https://github.com/ros2/libyaml_vendor.git
git clone -b humble https://github.com/ros2/spdlog_vendor.git
git clone -b humble https://github.com/ros2/rcl_logging.git
git clone -b humble https://github.com/ros2/rmw.git
git clone -b humble https://github.com/ros2/rmw_implementation.git
colcon build

Expected behavior

Build successful

Actual behavior

CMake Error as ROS middleware implementation is NOTFOUND

When I fail to have the CoreDX environment established, I get an error about being unable to load a library. Unfortunately, the error does not specify the library that failed to load (and it's typically a library several layers deep that failed to load). Please modify the code to look more like this:

    if (library_path.empty()) {
      RMW_SET_ERROR_MSG(("failed to find shared library of rmw implementation. Searched " + env_var).c_str());
      return nullptr;
    }
    try {
      lib = new Poco::SharedLibrary(library_path);
    } catch (Poco::LibraryLoadException& e) {
      RMW_SET_ERROR_MSG(("failed to load shared library of rmw implementation. Exception: " + e.displayText()).c_str());
      return nullptr;
    } catch (...) {
      RMW_SET_ERROR_MSG(("failed to load shared library of rmw implementation: " + library_path).c_str());
      return nullptr;
    }

Also note that the library-load code is duplicated in rosidl_typesupport.

It has been failing consistently since build 2116 (Oct 6, 2020)
Here's the history of the build: https://ci.ros2.org/view/nightly/job/nightly_osx_repeated/2162/testReport/junit/(root)/projectroot/test_create_destroy_node__rmw_fastrtps_cpp/history/

The test passes on nightly_osx_release.

Stacktrace

-- run_test.py: extra environment variables:
 - RMW_IMPLEMENTATION=rmw_fastrtps_cpp
-- run_test.py: invoking following command in '/Users/osrf/jenkins-agent/workspace/nightly_osx_repeated/ws/build/test_rmw_implementation':
 - /Users/osrf/jenkins-agent/workspace/nightly_osx_repeated/ws/build/test_rmw_implementation/test_create_destroy_node__rmw_fastrtps_cpp --gtest_output=xml:/Users/osrf/jenkins-agent/workspace/nightly_osx_repeated/ws/build/test_rmw_implementation/test_results/test_rmw_implementation/test_create_destroy_node__rmw_fastrtps_cpp.gtest.xml
Running main() from /Users/osrf/jenkins-agent/workspace/nightly_osx_repeated/ws/install/gtest_vendor/src/gtest_vendor/src/gtest_main.cc
[==========] Running 6 tests from 2 test suites.
[----------] Global test environment set-up.
[----------] 5 tests from TestNodeConstructionDestruction__rmw_fastrtps_cpp
[ RUN      ] TestNodeConstructionDestruction__rmw_fastrtps_cpp.create_with_bad_arguments
[       OK ] TestNodeConstructionDestruction__rmw_fastrtps_cpp.create_with_bad_arguments (45 ms)
[ RUN      ] TestNodeConstructionDestruction__rmw_fastrtps_cpp.destroy_with_bad_arguments
[       OK ] TestNodeConstructionDestruction__rmw_fastrtps_cpp.destroy_with_bad_arguments (7 ms)
[ RUN      ] TestNodeConstructionDestruction__rmw_fastrtps_cpp.create_and_destroy
[       OK ] TestNodeConstructionDestruction__rmw_fastrtps_cpp.create_and_destroy (7 ms)
[ RUN      ] TestNodeConstructionDestruction__rmw_fastrtps_cpp.create_with_internal_errors
libc++abi.dylib: terminating with uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument
/Users/osrf/jenkins-agent/workspace/nightly_osx_repeated/ws/src/ros2/rmw_fastrtps/rmw_fastrtps_shared_cpp/src/participant.cpp:143 Injecting fault and returning nullptr
/Users/osrf/jenkins-agent/workspace/nightly_osx_repeated/ws/src/ros2/rcutils/src/get_env.c:32 Injecting fault and returning "some string error"
/Users/osrf/jenkins-agent/workspace/nightly_osx_repeated/ws/src/ros2/rcutils/src/get_env.c:32 Injecting fault and returning "some string error"
/Users/osrf/jenkins-agent/workspace/nightly_osx_repeated/ws/src/ros2/rmw_fastrtps/rmw_fastrtps_cpp/src/publisher.cpp:57 Injecting fault and returning nullptr
/Users/osrf/jenkins-agent/workspace/nightly_osx_repeated/ws/src/ros2/rcutils/src/allocator.c:34 Injecting fault and returning ((void*)0)
/Users/osrf/jenkins-agent/workspace/nightly_osx_repeated/ws/src/ros2/rcutils/src/allocator.c:34 Injecting fault and returning ((void*)0)
/Users/osrf/jenkins-agent/workspace/nightly_osx_repeated/ws/src/ros2/rmw_fastrtps/rmw_fastrtps_cpp/src/subscription.cpp:62 Injecting fault and returning nullptr
/Users/osrf/jenkins-agent/workspace/nightly_osx_repeated/ws/src/ros2/rcutils/src/allocator.c:34 Injecting fault and returning ((void*)0)
/Users/osrf/jenkins-agent/workspace/nightly_osx_repeated/ws/src/ros2/rcutils/src/strdup.c:32 Injecting fault and returning ((void*)0)
/Users/osrf/jenkins-agent/workspace/nightly_osx_repeated/ws/src/ros2/rcutils/src/strdup.c:43 Injecting fault and returning ((void*)0)
/Users/osrf/jenkins-agent/workspace/nightly_osx_repeated/ws/src/ros2/rcutils/src/allocator.c:34 Injecting fault and returning ((void*)0)
/Users/osrf/jenkins-agent/workspace/nightly_osx_repeated/ws/src/ros2/rmw_fastrtps/rmw_fastrtps_shared_cpp/src/rmw_guard_condition.cpp:27 Injecting fault and returning nullptr
/Users/osrf/jenkins-agent/workspace/nightly_osx_repeated/ws/src/ros2/rmw_fastrtps/rmw_fastrtps_shared_cpp/src/listener_thread.cpp:47 Injecting fault and returning 1
/Users/osrf/jenkins-agent/workspace/nightly_osx_repeated/ws/src/ros2/rmw_fastrtps/rmw_fastrtps_shared_cpp/src/rmw_guard_condition.cpp:27 Injecting fault and returning nullptr
-- run_test.py: return code -6
-- run_test.py: generate result file '/Users/osrf/jenkins-agent/workspace/nightly_osx_repeated/ws/build/test_rmw_implementation/test_results/test_rmw_implementation/test_create_destroy_node__rmw_fastrtps_cpp.gtest.xml' with failed test
-- run_test.py: verify result file '/Users/osrf/jenkins-agent/workspace/nightly_osx_repeated/ws/build/test_rmw_implementation/test_results/test_rmw_implementation/test_create_destroy_node__rmw_fastrtps_cpp.gtest.xml'

Bug report

Required Info:

• Operating System:
  • custom
• Installation type:
  • from source
• Version or commit hash:
  • 31843ad (humble HEAD)
• DDS implementation:
  • FastDDS (but not really relevant)
• Client library (if applicable):
  • N/A

This isn't so much an issue as it is a question: #189 added a build dependency on ament_index_cpp to rmw_implementation:

From the rest of the CMakeLists.txt, ament_index_cpp only appears to be used when RMW_IMPLEMENTATION_DISABLE_RUNTIME_SELECTION is ON:

However, because find_package(ament_index_cpp ..) appears outside the if(..) else (..), it's always executed, which leads to problems on (build) platforms which do not support C++ nor runtime RMW selection.

Should line 15 be moved to somewhere around here, so it is also guarded by RMW_IMPLEMENTATION_DISABLE_RUNTIME_SELECTION?

If this would be OK, I could submit a PR introducing this change.

/home/pedestrian/ros2_java_ws/src/ros2/rmw_implementation/rmw_implementation/src/functions.cpp:367:16: error: ‘rmw_log_severity_t’ was not declared in this scope
1, ARG_TYPES(rmw_log_severity_t))
^
/home/pedestrian/ros2_java_ws/src/ros2/rmw_implementation/rmw_implementation/src/functions.cpp:176:19: note: in definition of macro ‘EXPAND’
#define EXPAND(x) x
^
/home/pedestrian/ros2_java_ws/src/ros2/rmw_implementation/rmw_implementation/src/functions.cpp:212:26: note: in expansion of macro ‘ARGS_1’
ReturnType name(EXPAND(ARGS_ ## _NR(VA_ARGS)))
^
/home/pedestrian/ros2_java_ws/src/ros2/rmw_implementation/rmw_implementation/src/functions.cpp:365:1: note: in expansion of macro ‘RMW_INTERFACE_FN’
RMW_INTERFACE_FN(rmw_set_log_severity,
^
/home/pedestrian/ros2_java_ws/src/ros2/rmw_implementation/rmw_implementation/src/functions.cpp:367:6: note: in expansion of macro ‘ARG_TYPES’
1, ARG_TYPES(rmw_log_severity_t))
^
/home/pedestrian/ros2_java_ws/src/ros2/rmw_implementation/rmw_implementation/src/functions.cpp:213:3: error: expected ‘,’ or ‘;’ before ‘{’ token
{
^
/home/pedestrian/ros2_java_ws/src/ros2/rmw_implementation/rmw_implementation/src/functions.cpp:365:1: note: in expansion of macro ‘RMW_INTERFACE_FN’
RMW_INTERFACE_FN(rmw_set_log_severity,
^
/home/pedestrian/ros2_java_ws/src/ros2/rmw_implementation/rmw_implementation/src/functions.cpp:421:1: error: expected ‘}’ at end of input
}
^
CMakeFiles/rmw_implementation.dir/build.make:62: recipe for target 'CMakeFiles/rmw_implementation.dir/src/functions.cpp.o' failed
make[2]: *** [CMakeFiles/rmw_implementation.dir/src/functions.cpp.o] Error 1
CMakeFiles/Makefile2:99: recipe for target 'CMakeFiles/rmw_implementation.dir/all' failed
make[1]: *** [CMakeFiles/rmw_implementation.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2

<== Command '. /home/pedestrian/ros2_java_ws/build_isolated/rmw_implementation/cmake__build.sh && /usr/bin/make -j8 -l8' failed in '/home/pedestrian/ros2_java_ws/build_isolated/rmw_implementation' with exit code '2'
<== Command '. /home/pedestrian/ros2_java_ws/build_isolated/rmw_implementation/cmake__build.sh && /usr/bin/make -j8 -l8' failed in '/home/pedestrian/ros2_java_ws/build_isolated/rmw_implementation' with exit code '2'

--- stderr: rmw_implementation                                           
CMake Error at /home/abc/ros2_foxy/install/rmw_implementation_cmake/share/rmw_implementation_cmake/cmake/get_default_rmw_implementation.cmake:60 (message):
  Could not find ROS middleware implementation 'rmw_opensplice_cpp'.  Choose
  one of the following: rmw_cyclonedds_cpp, rmw_fastrtps_cpp,
  rmw_fastrtps_dynamic_cpp
Call Stack (most recent call first):
  CMakeLists.txt:22 (get_default_rmw_implementation)


---
Failed   <<< rmw_implementation [5.78s, exited with code 1]
Aborted  <<< actionlib_msgs [3.68s]                  
Aborted  <<< geometry_msgs [7.18s]                   
Aborted  <<< ament_pclint [1.14s]                          

Summary: 154 packages finished [55.9s]
  1 package failed: rmw_implementation
  3 packages aborted: actionlib_msgs ament_pclint geometry_msgs
  2 packages had stderr output: rmw_implementation tracetools_trace
  154 packages not processed

How to resolve this issue, Even I try to export RWM_IMPLEMENTATION with available options but they can work with colcon build for ros2 foxy

If you have a multi-element AMENT_PREFIX_PATH that contains the same RMW implementation twice, then you can get an error like this:

CMake Error at /Users/gerkey/ros2_ws/install/share/rmw_implementation/cmake/add_executable_for_each_rmw_implementation.cmake:66 (add_executable):
  add_executable cannot create target "intrapc__rmw_opensplice_cpp" because
  another target with the same name already exists.  The existing target is
  an executable created in source directory
  "/Users/gerkey/ros2_ws/src/ros2/demos/intra_process_comms".  See
  documentation for policy CMP0002 for more details.
Call Stack (most recent call first):
  CMakeLists.txt:21 (add_executable_for_each_rmw_implementations)

I confirmed that get_available_rmw_implementations() was returning a list with duplicates: rmw_opensplice_cpp;rmw_opensplice_cpp.

In this case, my AMENT_PREFIX_PATH was:

AMENT_PREFIX_PATH=/Users/gerkey/ros2_ws/install:/Users/gerkey/ros2_install/ros2

I had previously sourced the setup file for a binary install (the ros2_install element). I had also sourced the setup file from install tree where I was building, but that shouldn't be a problem.

Now, perhaps I'm in the wrong for getting into this configuration, but it would be good to fix, or at least get a better error message.

I'm inclined to REMOVE_DUPLICATES inside get_available_rmw_implementations(), but am open to other options.

Looking at https://github.com/ros2/rmw/blob/876645761751fc0be3fdaf4bf23d87b408f3e8b4/rmw_implementation_cmake/cmake/get_default_rmw_implementation.cmake, I thought you could specify the default rmw implementation through ament build --cmake-args -DRMW_IMPLEMENTATION or the environment variable RMW_IMPLEMENTATION

I can't do either, and I think it's because of this: 5eff3ff#diff-e874e8ccc0d49455417259661b3f88f5R17

The configured rmw_implementation-extras.cmake is always setting the default rmw implementation to whatever the default was when it was configured.

I want to build the rclcpp_examples package with a specific rmw implementation as default, which is different to the default when I built rmw_implementation. If I change the part of 5eff3ff which affects rmw_implementation-extras.cmake back to how it was, I can set the default rmw implementation through either the environment variable or the cmake args as expected.

Should I be allowed to set the default rmw implementation for rclcpp_examples independently to the default used to build rmw_implementation? Since get_default_rmw_implementation is being used everywhere I thought the answer was yes, but maybe this is the expected behaviour. If so I'd like to add a message that explains why the requested defaults are being ignored.

Reviewing the package.xml of rmw_implementation, it <depend>s on rmw_implementation_cmake which it wrong because this package is pure cmake. this should be changed to `<buildtool_export_depend>, right ?

Bug report

Required Info:

• Operating System:
  • ubuntu 20.04
• Installation type:
  • binary
• Version or commit hash:
  • 1.0.3-1focal.20220209.142624
• DDS implementation:
  • rmw_cyclonedds_cpp
• Client library (if applicable):
  • N/A

Steps to reproduce issue

apt-cache show ros-foxy-rmw-implementation | grep-dctrl --no-field-names --show-field=Depends --field=Depends 'ros-foxy-rmw-cyclonedds-cpp'

Expected behavior

ros-foxy-rmw-implementation has ros-foxy-rmw-cyclonedds-cpp in its Depends.

Actual behavior

ros-foxy-rmw-implementation does not have ros-foxy-rmw-cyclonedds-cpp in its Depends.

Additional information

https://github.com/ros2-gbp/rmw_implementation-release/blob/debian/foxy/focal/rmw_implementation/debian/control

rmw_implementation has a python funtion called get_available_rmw_implementations. This function is being used in ros2cli in some of these packages' test

I have created this issue according with this PR #73 (comment)

Context
There's a race condition in handling a sigint that only occurs when multiple rmw implementations are supported.

In our test suite it manifests as a timeout when test executables have the correct output and shutdown is triggered by launch_testing, but they don't respond to the sigint correctly, e.g. http://ci.ros2.org/view/nightly/job/nightly_osx_repeated/769/testReport/junit/(root)/projectroot/test_tutorial_list_parameters__rmw_fastrtps_cpp/

You'll see from this job that if only one rmw implementation is available (rmw_fastrtps_cpp in this case), the test can pass fine 150 times:

Cause
I think this would have started occurring since ros2/launch#44

I've traced it to this line:

I think the problem is that the lib variable is static and is being destroyed on shutdown too early. I'm not yet an expert in the workings of rmw_implementation/memory management so if someone could confirm that that "make sense" that would be appreciated.

Fix
If that's a reasonable cause, is an appropriate fix to make the lib variable not static? Or does it need to be static because of particular implementation details and we should instead implement a workaround to prevent it from being used after destructed?

At present, the current CMakeLists.txt seems a bit too implicit:
https://github.com/ros2/rmw_implementation/blob/c5f5324/rmw_implementation/CMakeLists.txt#L41-L44

Can this be made into an explicit CMake switch, something like -DFORWARD_RMW_IMPLEMENTATION={OFF,ON}?

Rationale:
I'm developing on a machine that only has one RMW implementation present.
In debugging stuff like ros2/rcpputils#3 and ros2/rcutils#143, it I couldn't just rebuild rmw_implementation to reproduce what I have installed as a binary.

The only way that I can reproduce the binary is either (a) modify CMakeLists.txt or (b) install an (unused) RMW implementation, which is odd... (example patch line)

I should be able reproduce this with my installed packages?

While investigating the causes behind ros2/rmw_cyclonedds#279 , we discovered that there is no test within ROS 2 that actually does a rmw_take_sequence and then checks on the results. We do have a test that is pretty close: https://github.com/ros2/rcl/blob/7a25a74cf911840224fb5b992d118c22c825f961/rcl/test/rcl/test_subscription.cpp#L388 . That initializes the sequence, fills it with messages, and then calls rcl_take_sequence.

It would be nice to have another variant of this test in this repository which specifically deals with rmw_take_sequence.

If a user is specifying RMW_IMPLEMENTATION={valid_but_not_installed} when running a node, if there are multiple rmw implementations installed, an error is raised.

However, if a user only has one rmw implementation installed, from what I understand that code path is never reached. It's not obvious that specifying RMW_IMPLEMENTATION={valid_but_not_installed} doesn't do anything. (I assumed I had connext installed and only noticed I was still using fastrtps because of an error message).

It would be good to at least warn the user in this case.

Bug report

Required Info:

• Operating System:
  • macOS Mojave
• Installation type:
  • source
• Version or commit hash:
  • `master`
• DDS implementation:
  • Connext
• Client library (if applicable):
  • rclcpp

Steps to reproduce issue

Run macOS CI

Expected behavior

Test passes consistently

Actual behavior

It has failed 2 out of the latest 3 nightlies

Additional information

Test history

-- run_test.py: extra environment variables:
 - RMW_IMPLEMENTATION=rmw_connextdds
-- run_test.py: invoking following command in '/Users/osrf/jenkins-agent/workspace/nightly_osx_release/ws/build/test_rmw_implementation':
 - /Users/osrf/jenkins-agent/workspace/nightly_osx_release/ws/build/test_rmw_implementation/test_service__rmw_connextdds --gtest_output=xml:/Users/osrf/jenkins-agent/workspace/nightly_osx_release/ws/build/test_rmw_implementation/test_results/test_rmw_implementation/test_service__rmw_connextdds.gtest.xml
Running main() from /Users/osrf/jenkins-agent/workspace/nightly_osx_release/ws/install/gtest_vendor/src/gtest_vendor/src/gtest_main.cc
[==========] Running 12 tests from 2 test suites.
[----------] Global test environment set-up.
[----------] 8 tests from TestService__rmw_connextdds
[ RUN      ] TestService__rmw_connextdds.create_and_destroy
[       OK ] TestService__rmw_connextdds.create_and_destroy (361 ms)
[ RUN      ] TestService__rmw_connextdds.create_and_destroy_native
[       OK ] TestService__rmw_connextdds.create_and_destroy_native (338 ms)
[ RUN      ] TestService__rmw_connextdds.create_with_bad_arguments
[ERROR] [1619169487.713835594] [rmw_connextdds]: invalid service name
[ERROR] [1619169487.713895383] [rmw_connextdds]: invalid service name: topic name must not contain characters other than alphanumerics, '_', or '/'
[ERROR] [1619169487.713913222] [rmw_connextdds]: invalid service name: topic name must be absolute, it must lead with a '/'
[ERROR] [1619169487.715329136] [rmw_connextdds]: unsupported history kind: 3
[ERROR] [1619169487.715351609] [rmw_connextdds]: failed to convert writer QoS
[ERROR] [1619169487.715367751] [rmw_connextdds]: failed to create DDS writer
[ERROR] [1619169487.715484760] [rmw_connextdds]: failed to create service replier
[ERROR] [1619169487.715504764] [rmw_connextdds]: failed to create RMW service implementation
[ERROR] [1619169487.715528708] [rmw_connextdds]: failed to load required fastrtps service type support. 
Received these errors:
C: 'Handle's typesupport identifier (not-a-typesupport-identifier) is not supported by this library, at /Users/osrf/jenkins-agent/workspace/nightly_osx_release/ws/src/ros2/rosidl_typesupport/rosidl_typesupport_c/src/type_support_dispatch.hpp:115'
CPP: 'Handle's typesupport identifier (not-a-typesupport-identifier) is not supported by this library, at /Users/osrf/jenkins-agent/workspace/nightly_osx_release/ws/src/ros2/rosidl_typesupport/rosidl_typesupport_c/src/type_support_dispatch.hpp:115'

>>> [rcutils|error_handling.c:108] rcutils_set_error_state()
This error state is being overwritten:

  'failed to load required fastrtps service type support. 
Received these errors:
C: 'Handle's typesupport identifier (not-a-typesupport-identifier) is not supported by this library, at /Users/osrf/jenkins-agent/workspace/nightly_osx_release/ws/src/ros2/rosidl_typesupport/rosidl_typesupport_c/src/type_support_dispatch.hpp:115'
CPP: 'Handle's typesupport identifier (not-a-typesupport-identifier) is not supported by this library, at /Users/osrf/jenkins-agent/workspace/nightly_osx_release/ws/src/ros2/rosidl_typesupport/rosidl_typesupport_c/src/type_support_dispatch.hpp:115', at /Users/osrf/jenkins-agent/workspace/nightly_osx_release/ws/src/ros2/rmw_connextdds/rmw_connextdds_common/src/common/rmw_type_support.cpp:767'

with this new error message:

  'Handle's typesupport identifier (not-a-typesupport-identifier) is not supported by this library, at /Users/osrf/jenkins-agent/workspace/nightly_osx_release/ws/src/ros2/rosidl_typesupport/rosidl_typesupport_c/src/type_support_dispatch.hpp:115'

rcutils_reset_error() should be called after error handling to avoid this.
<<<
[ERROR] [1619169487.715574618] [rmw_connextdds]: failed to load required fastrtps service type support. 
Received these errors:
C: 'Handle's typesupport identifier (not-a-typesupport-identifier) is not supported by this library, at /Users/osrf/jenkins-agent/workspace/nightly_osx_release/ws/src/ros2/rosidl_typesupport/rosidl_typesupport_c/src/type_support_dispatch.hpp:115'
CPP: 'Handle's typesupport identifier (not-a-typesupport-identifier) is not supported by this library, at /Users/osrf/jenkins-agent/workspace/nightly_osx_release/ws/src/ros2/rosidl_typesupport/rosidl_typesupport_c/src/type_support_dispatch.hpp:115'
[ERROR] [1619169487.715588371] [rmw_connextdds]: failed to lookup type supports for service
[ERROR] [1619169487.715600801] [rmw_connextdds]: failed to create RMW service implementation
[       OK ] TestService__rmw_connextdds.create_with_bad_arguments (342 ms)
[ RUN      ] TestService__rmw_connextdds.create_with_internal_errors
[ERROR] [1619169488.056449310] [rmw_connextdds]: failed to create RMW service
[ERROR] [1619169488.057492143] [rmw_connextdds]: failed to allocate service name
/Users/osrf/jenkins-agent/workspace/nightly_osx_release/ws/src/ros2/rcutils/src/allocator.c:34 Injecting fault and returning ((void*)0)
/Users/osrf/jenkins-agent/workspace/nightly_osx_release/ws/src/ros2/rcutils/src/allocator.c:34 Injecting fault and returning ((void*)0)
[       OK ] TestService__rmw_connextdds.create_with_internal_errors (335 ms)
[ RUN      ] TestService__rmw_connextdds.destroy_with_internal_errors
/Users/osrf/jenkins-agent/workspace/nightly_osx_release/ws/src/ros2/rcutils/src/allocator.c:50 Injecting fault and returning ((void*)0)
PRESPsReaderQueue_storeSampleData:deserialize sample error in topic 'ros_discovery_info' with type 'rmw_dds_common::msg::dds_::ParticipantEntitiesInfo_'
[       OK ] TestService__rmw_connextdds.destroy_with_internal_errors (344 ms)
[ RUN      ] TestService__rmw_connextdds.take_request_with_bad_arguments
[       OK ] TestService__rmw_connextdds.take_request_with_bad_arguments (340 ms)
[ RUN      ] TestService__rmw_connextdds.send_reponse_with_bad_arguments
[       OK ] TestService__rmw_connextdds.send_reponse_with_bad_arguments (344 ms)
[ RUN      ] TestService__rmw_connextdds.send_reponse_with_client_gone
/Users/osrf/jenkins-agent/workspace/nightly_osx_release/ws/src/ros2/rmw_implementation/test_rmw_implementation/test/test_service.cpp:479: Failure
Expected equality of these values:
  0
  ret
    Which is: 2
error not set
[  FAILED  ] TestService__rmw_connextdds.send_reponse_with_client_gone (1298 ms)
[----------] 8 tests from TestService__rmw_connextdds (3702 ms total)

[----------] 4 tests from TestServiceUse__rmw_connextdds
[ RUN      ] TestServiceUse__rmw_connextdds.destroy_with_null_node
[       OK ] TestServiceUse__rmw_connextdds.destroy_with_null_node (343 ms)
[ RUN      ] TestServiceUse__rmw_connextdds.destroy_null_service
[       OK ] TestServiceUse__rmw_connextdds.destroy_null_service (344 ms)
[ RUN      ] TestServiceUse__rmw_connextdds.destroy_with_node_of_another_impl
[       OK ] TestServiceUse__rmw_connextdds.destroy_with_node_of_another_impl (335 ms)
[ RUN      ] TestServiceUse__rmw_connextdds.destroy_service_of_another_impl
[       OK ] TestServiceUse__rmw_connextdds.destroy_service_of_another_impl (344 ms)
[----------] 4 tests from TestServiceUse__rmw_connextdds (1367 ms total)

[----------] Global test environment tear-down
[==========] 12 tests from 2 test suites ran. (5069 ms total)
[  PASSED  ] 11 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] TestService__rmw_connextdds.send_reponse_with_client_gone

 1 FAILED TEST
-- run_test.py: return code 1
-- run_test.py: inject classname prefix into gtest result file '/Users/osrf/jenkins-agent/workspace/nightly_osx_release/ws/build/test_rmw_implementation/test_results/test_rmw_implementation/test_service__rmw_connextdds.gtest.xml'
-- run_test.py: verify result file '/Users/osrf/jenkins-agent/workspace/nightly_osx_release/ws/build/test_rmw_implementation/test_results/test_rmw_implementation/test_service__rmw_connextdds.gtest.xml'

https://github.com/osrf/buildfarmer/issues/181