[ros-users] [Discourse.ros.org] [Next Generation ROS] Adding clang thread safety analysis for ROS2 core packages
Emerson Knapp via Discourse.ros.org
ros.discourse at gmail.com
Thu Feb 28 21:00:14 UTC 2019
I've hit a wall with enabling this - given the following constraint
* we do not want to make our own Mutex wrapper, in favor of using `std::mutex`
High level problem -
1. To get the `capability` annotations on `std::mutex`, I need to use `libc++` (LLVM)
1. On Linux, by default, all libraries use `libstd++` (GNU)
1. The build, using `libc++` on an annotated package, can succeed just fine, BUT
1. Any std objects passed across `.so` boundaries into this library now have runtime undefined behavior, because you call `libc++` functions on `libstdc++`-created objects
Specific example case that I ran into -
* I add thread safety annotation to `rmw_fastrtps_shared_cpp`
* link it to `libc++` to have `std::mutex` be analyzable
* upstream, an `rclcpp` test creates a Node, which eventually resolves to `fastrtps_shared_cpp::rmw_node.cpp::__rmw_create_node`, which:
* creates a `ParticipantAttributes` from `fastrtps` (which has not been modified, so it uses `libstdc++` `std::vector` creation)
* calls `vector::resize` on the member vector (which jumps into the `libc++` implementation)
* program hangs
* slight variations on operations can cause a crash
Workarounds I've tried:
* `colcon build --cmake-args -DCMAKE_CXX_FLAGS=-stdlib=libc++` (mixin approach)
* FAILS (on Linux) because `poco_vendor` is not built in the ROS2 workspace, and we get stdlib linker errors against it
* `rmw_shared_cpp-extras.cmake` with the `-stdlib=libc++` block
* FAILS for same reason
In conclusion, here are a list of options I have come up with to move forward (I am also very open to other suggestions)
1. When we run this analysis, `libc++` linking flag that is turned on by the build caller, not specified at the package level
* Static analysis runs on compilation, giving useful warning messages
* We cannot expect linking or running code to work
* So, somehow disable linking?
1. Build _all_ code from source, allowing forcing the standard library for all code
* looking at `libpoco` specificially here
1. Run this analysis on Mac only, where all the code will be linked against LLVM `libc++`
1. Remove the initially stated constraint and provide our own annotated `mutex` wrapper, removing the need for `libc++`
1. Modify Fast-RTPS interfaces to remove the need to interact with `std::` containers directly
* This may not be the only place where `std::` objects are used across API boundaries, but it's the place I identified in my first annotations
@tfoote thoughts?
I think this analysis is valuable, but it's definitely got its technical hangups here
@Thomas_Moulard
---
[Visit Topic](https://discourse.ros.org/t/adding-clang-thread-safety-analysis-for-ros2-core-packages/7930/14) or reply to this email to respond.
More information about the ros-users
mailing list