Unity hangs when client is waiting for service being debugged

[moccij]

Hi,

By calling the desired service with Call(request) from a Unity client, the service implemented on another C++ process executes its callback and builds the response, so that Unity can receive and process it. Under normal conditions the Unity client is always able to process the response, even when the C++ service callback takes time to complete the callback.

If the C++ service callback hits a debugger breakpoint and then gets resumed after some time (20secs), then the Unity client never receives the response and hangs, unable to recover. If the callback gets resumed very early then the Unity client is more likely to receive the response.

This behavior is not observed when calling the service from a C++ or Python client (ex. with rqt).

All ROS2 binaries are built for Windows x64 from ROS2 Humble sources. The connector binaries are also compiled in the same way. Debugging is done with cdb.

This problem is reproduced on multiple machines, with both Windows 10 and Windows 11.

[krosthw]

Same problem here!
also for the example in this repo: ros2cs_examples/ROS2Client + ROS2Service the Call method never returns.
Calling the service from rqt, it returns the expected result.

[Deric-W]

also for the example in this repo: ros2cs_examples/ROS2Client + ROS2Service the Call method never returns.

I can confirm this, when changing the client to use the wait set I totally forgot to spin in the example, which is why the client example does not handle incoming responses.

I will create a PR to update the examples soon, but that won't fix the strange behavior with the debugged service.

When I have time I will create a C example to test what the C++ implementation does in addition to the calls ros2cs does.