UrDriver destructor hangs if arm is unreachable

[acmorrow]

Affected Client Library version(s)

2.2.0

What combination of platform is the Client Library running on.

Linux

How did you install the Client Library

Build the library from source

Which robot platform is the library connected to.

URSim in linux, URSim in docker

Robot SW / URSim version(s)

UR20

How are you using the Client Library

Headless without using the teach pendant

Issue details

Summary

It seems that when destroying a UrDriver object, that if the simulator is not reachable because it has been terminated, that the UrDriver destructor hangs forever attempting to reconnect. It looks like this happens when trying to disconnect the primary interface, because I can also get a hang by calling stopPrimaryClientCommunication in this scenario (I tried this because I thought maybe I needed to do it before letting the UrDriver destructor run).

Issue details

Steps to Reproduce

• Start the simulator
• Construct a UrDriver object that connects to it.
• ^C the simulator
• Try to destroy the UrDriver object (or, call stopPrimaryClientCommunication on it).

Expected Behavior

I'd expect to be able to destroy a UrDriver object whether or not the remote side is available. I did this with the simulator, but I'd expect the same behavior against a real arm, as I don't see anything in the driver that makes this simulator specific.

Actual Behavior

The following log is repeated indefinitely:

URCL - /src/build/_deps/universal_robots_client_library-src/src/comm/tcp_socket.cpp 144: Failed to connect to robot on IP 192.168.56.101:30001. Please check that the robot is booted and reachable on 192.168.56.101. Retrying in 10 seconds.

Workaround Suggestion

I have been unable to find a workaround yet. I've looked at the various methods on UrDriver, and none of them seem to be relevant. Possibly, I've failed to configure something correctly with the UrDriverConfiguration that is putting it into a mode where it retries indefinitely? Or there is some other action I need to take in order to tell the library that I don't want it to try to auto-recover in this case?

Relevant log output

Accept Public visibility

• I agree to make this context public

[urfeex]

Yes, I've seen that around, thanks for reporting it. I never took it too important, but it is definitively a small bug.