Gazebo issues on Windows Subsystem for Linux (WSL)

Issue #2351 new
Silvio Traversaro
created an issue

I recently discover that a few users of gazebo-yarp-plugins are using Gazebo on WSL (a.k.a. Ubuntu on Windows, https://msdn.microsoft.com/en-us/commandline/wsl/about ). See https://bitbucket.org/osrf/gazebo_tutorials/pull-requests/364/tutorial-for-installing-on-ubuntu-on/diff for a tutorial on how to run Gazebo on WSL.

For middleware that support Windows such as YARP, this is an interesting alternative to get Gazebo running on Windows, because it permits to have just the minimum amount of Gazebo-related code running under WSL, while the rest of the software can run on the actual Windows system, communicating with WSL-processes using regular network sockets.

However, I noticed some WSL-specific problem in Gazebo, that I think it is worth reporting (even if most of them are actually WSL bugs).

Error setting socket option (IP_MULTICAST_IF)

Related WSL issue: https://github.com/Microsoft/BashOnWindows/issues/990

Problem

All code using ignition-transport (including Gazebo 8 and 9) fails on the regular WSL with the following error:

Error setting socket option (IP_MULTICAST_IF).
Error setting socket option (IP_MULTICAST_IF).
Did you set the environment variable IGN_IP with a correct IP address?
  [192.168.1.100] seems an invalid local IP address.
  Using 127.0.0.1 as hostname.
terminate called after throwing an instance of 'std::out_of_range'
  what():  vector::_M_range_check: __n (which is 0) >= this->size() (which is 0)
Aborted (core dumped)

This is due to the fact that the IP_MULTICAST_IF socket option is not supported in the released version of WSL, and support for it have been introduced only in Windows build 16176 ( https://github.com/Microsoft/BashOnWindows/issues/990 ) that is currently only available if you use the "Insider" version of Windows.

Possible solutions

I am not an expert of the schedule of Windows update, but I think waiting for the fix to be released is the easiest option. People interested in running the latest version of Gazebo in the meanwhile can update to the "Insider" version of Windows.

clock_nanosleep with clockid CLOCK_REALTIME fails with error EINVAL

Related WSL issue: https://github.com/Microsoft/BashOnWindows/issues/2503

Related Gazebo issue: https://bitbucket.org/osrf/gazebo/issues/2058/use-clock_monotonic-in-sleep-and-timer

Problem

Both the gazebo::common::Time::Sleep(...) and ign::common::Time::Sleep(...) methods use the system call clock_nanosleep(CLOCK_REALTIME, ... ) to sleep the current thread. However, clock_nanosleep in WSL works only with the clock CLOCK_MONOTONIC. I opened an issue for this on WSL issue tracker https://github.com/Microsoft/BashOnWindows/issues/2503 , but I don't it will be solved anytime soon.

Possible solutions

One possible solution is to check if clock_nanosleep(CLOCK_REALTIME, ...) is supported during the Time class initialization, and switch otherwise to use clock_nanosleep(CLOCK_MONOTONIC, ...) . A more complicated possible solution is to migrate the Time classes to the new C++11 <chrono> functions, that seem to work fine also on WSL (even if I imagine that they are internally implemented using the clock_nanosleep system calls. Apparently switching to CLOCK_MONOTONIC was already planned to avoid problems with system clock reset (see https://bitbucket.org/osrf/gazebo/issues/2058/use-clock_monotonic-in-sleep-and-timer) so that would be the easier solution.