-
Notifications
You must be signed in to change notification settings - Fork 0
test_action_client_server__Fibonacci fails on aarch64 repeated #152
Comments
Still looking into this. First impression is the action server did not shut down after receiving |
Alright, it seems we have a race condition when triggering guard conditions to wake up wait sets when a signal comes in. Here's the backtrace:
There you can see that while we're about to wait on a wait set (having this mutex locked), a signal comes along and attempts to lock that same mutex. We've been discussing with @wjwwood a solution. It'll likely involve deferring some of the work the signal handler is currently doing to a separate thread. |
Edit: oops, I didn't look closely enough at the test output |
It blocks with both? I can imagine why it does for ros2/rclcpp#605, but I'd have to look into |
@sloretz did you mean ros2/rclcpp#607 instead of 608 here too? |
Oops, I think I didn't look closely enough here. With ros2/rclcpp#605 I haven't seen this test failure where the server hangs. Instead I see a different issue less frequently where the client fails to find the server in |
I don't see this test failure in the latest nightly repeated aarch64 job. Since ros2/rclcpp#605 was merged I'm going to close this as fixed by that PR. |
Last night one of the test failures on aarch64 repeated was test_action_client_server__Fibonacci: https://ci.ros2.org/view/nightly/job/nightly_linux-aarch64_repeated/624/testReport/junit/test_communication.build.test_communication/test_action_client_server__Fibonacci__rclcpp__rmw_fastrtps_cpp_/test_action_client_server/ . The output was:
@jacobperron @sloretz FYI
The text was updated successfully, but these errors were encountered: