Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test failures: subscription already associated with a wait set #1101

Open
christophfroehlich opened this issue Apr 17, 2024 · 3 comments
Open
Labels

Comments

@christophfroehlich
Copy link
Contributor

christophfroehlich commented Apr 17, 2024

[INFO] [1713388339.950896541] [test_joint_group_velocity_controller]: activate successful
unknown file: Failure
C++ exception with description "subscription already associated with a wait set" thrown in the test body.

in rolling builds
https://github.com/ros-controls/ros2_controllers/actions/runs/8728644425/job/23948909083?pr=1100
and in debian source build
https://github.com/ros-controls/ros2_controllers/actions/runs/8728644426/job/23948908730

might be related to ros2/rclcpp#2142

@christophfroehlich
Copy link
Contributor Author

👀 @bmagyar they confirmed in the linked PR that this is not possible any more. You said you have a different approach for the test structure?

@christophfroehlich
Copy link
Contributor Author

@dhood as you brought yourself into the topic, do you maybe have an idea how to fix that temporarily?

@dhood
Copy link

dhood commented Apr 26, 2024

yes, curiosity got the better of me, I'm a sucker for CI that needs troubleshooting 😇

Perhaps explicitly removing the subscription from the waitset after it's been waited on, in wait_for? might be hanging onto a reference by the time the spin_some gets called. I opened #1106 hoping it would run CI for me but no such luck.

Otherwise an alternate approach to avoid waitsets could be an async wait on the underlying rt_command_ptr_ to be set away from null (in combination with spin_until_future_complete), but not as nice. Maybe something else is possible with the default callback group of the node not having that parameter true that William mentioned, but I imagine it would affect something else on those nodes accidentally..?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants