Closed bmartin427 closed 5 months ago
If using fastDDS the above valgrind complaint will not appear. However I do believe the failure to shut down correctly is the fault of rclcpp and not any rmw implementation: that is, the context and the guard condition both own each other via
std::shared_ptr
s, so neither can ever be deleted. PossiblyGuardCondition
should be holding a weak pointer to the context instead?
Yeah, I did something like this in #2400 on the rolling
branch. I'm not totally convinced that is correct either, because it seems possible for one of them to go out of scope without the other, but it has been in there a while now and seems to be OK.
i verified with https://github.com/ros2/ros2/commit/4d07f58591920794676261a14c2ba9d0a7bf2746, reported complain cannot be observed in mainline.
@bmartin427 it would be appreciated if you can check and close this issue.
I tested with ros-rolling-rclcpp=27.0.0-1jammy.20240216.162604
and confirmed I was not able to reproduce the problem.
Bug report
Required Info:
Steps to reproduce issue
Compile the following standalone executable and run with
RMW_IMPLEMENTATION=rmw_cyclonedds_cpp valgrind --leak-check=full
:(Abusing
GuardCondition
as a 'sub-context' here is a simplified stand-in forGraphListener
which is created as a sub-context byNodeGraph
on behalf ofNode
, and itself owns aGuardCondition
constructed with astd::shared_ptr
to the context.)Expected behavior
Optimally, no complaints, however there will be a couple leaks from liblttng-ust.so outside the scope of this issue.
Actual behavior
In addition to the above, this complaint:
Additional information
If using fastDDS the above valgrind complaint will not appear. However I do believe the failure to shut down correctly is the fault of rclcpp and not any rmw implementation: that is, the context and the guard condition both own each other via
std::shared_ptr
s, so neither can ever be deleted. PossiblyGuardCondition
should be holding a weak pointer to the context instead?