Closed danzimmerman closed 1 year ago
Possibly related issues
https://github.com/ros2/ros2/issues/844 https://github.com/ros2/ros2_documentation/issues/488 https://answers.ros.org/question/356763/ros2-windows-rmw_implementation-error-when-running-examples/
Can confirm according to the second link that CLI commands like ros2 topic list
throw the same error.
(humble) c:\Code\>mamba list | findstr openssl
openssl 1.1.1q h8ffe710_0 conda-forge
pyopenssl 22.0.0 pyhd8ed1ab_0 conda-forge
(humble) c:\code>mamba list | findstr openssl
openssl 1.1.1q h8ffe710_0 conda-forge
pyopenssl 22.0.0 pyhd8ed1ab_0 conda-forge
Just to clarify - in our case the issue cannot be related to OpenSSL as both working and broken configs are the same?
@Tobias-Fischer Yes, looks that way, doesn't seem to be OpenSSL version issue at least.
Trying to downgrade ros-humble-fastrtps
to match the working config's 2.6.1
, which will only change that package:
However, no change:
(humble) C:\code\ros\humble_ws>ros2 topic list
[ERROR] [1661120351.902239800] [rcl]:
Error getting RMW implementation identifier / RMW implementation not installed (expected identifier of 'rmw_fastrtps_cpp'),
with error message 'failed to load shared library 'rmw_fastrtps_cpp.dll' due to LoadLibrary error: 126,
at C:\bld\ros-humble-rcutils_1655024829144\work\ros-humble-rcutils\src\work\src\shared_library.c:159,
at C:\bld\ros-humble-rmw-implementation_1655039337688\work\ros-humble-rmw-implementation\src\work\src\functions.cpp:67',
exiting with 1.,
at C:\bld\ros-humble-rcl_1655040514413\work\ros-humble-rcl\src\work\src\rcl\rmw_implementation_identifier_check.c:145
(humble) C:\code\ros\humble_ws>mamba list | findstr fastrtps
ros-humble-fastrtps 2.6.1 py39hf2f0fb7_0 robostack-humble
ros-humble-fastrtps-cmake-module 2.2.0 py39he8739fe_1 robostack-humble
ros-humble-rmw-fastrtps-cpp 6.2.1 py39he8739fe_0 robostack-humble
ros-humble-rmw-fastrtps-dynamic-cpp 6.2.1 py39he8739fe_0 robostack-humble
ros-humble-rmw-fastrtps-shared-cpp 6.2.1 py39he8739fe_0 robostack-humble
ros-humble-rosidl-typesupport-fastrtps-c 2.2.0 py39he8739fe_0 robostack-humble
ros-humble-rosidl-typesupport-fastrtps-cpp 2.2.0 py39he8739fe_0 robostack-humble
@danzimmerman I followed your instructions, but I am unable to reproduce your problem. My mamba list is:
@traversaro Thanks, I'll diff that against mine and see if I can isolate my problem.
@traversaro There aren't many differences in packages, and nothing that seems relevant 🤔
Yours (ST) Mine (DZ)
ST: graphviz 5.0.1 had6c3a3_0 conda-forge
DZ: graphviz 5.0.0 had6c3a3_0 conda-forge
ST: jsonschema 4.14.0 pyhd8ed1ab_0 conda-forge
DZ: jsonschema 4.9.1 pyhd8ed1ab_0 conda-forge
ST: setuptools 65.1.1 py39hcbf5309_0 conda-forge
DZ: setuptools 65.1.0 py39hcbf5309_0 conda-forge
My suspect is that one of us has something corrupting/interfering with the system/environment in some way.
It seems that a LoadLibrary Error 126
can be a dependency error.
Checking deps of rmw_fastrtps_cpp.dll
with DUMPBIN
However, this doesn't seem like it should be an issue. All of the dependencies except KERNEL32.dll
ship in the Library/bin
folder.
import os
import pathlib
from subprocess import check_output
dll_path = pathlib.Path(os.environ['CONDA_PREFIX']) / 'Library/bin'
DLL_NAME = 'rmw_fastrtps_cpp.dll'
print(f'??? Checking DLL Path {dll_path} for dependencies of {DLL_NAME}')
dumpbin_output_string = check_output(['DUMPBIN', '/DEPENDENTS', (dll_path / DLL_NAME).as_posix()]).decode('UTF-8')
deps_list = dumpbin_output_string.split('dependencies:')[1].split('Summary')[0].strip().split()
# make them all lowercase so the check isn't case dependent
env_dlls = [fn.lower() for fn in os.listdir(dll_path) if fn.count('.dll')]
not_in_env_dlls = [fn for fn in deps_list if not fn.lower() in env_dlls]
in_env_dlls = [fn for fn in deps_list if fn.lower() in env_dlls]
print(f'\n>>> Found {len(in_env_dlls)} of {len(deps_list)} dependencies in {dll_path}:\n{in_env_dlls}')
print(f'\n>>> Did not find these DLLs in {dll_path}:\n{not_in_env_dlls}')
Gives
??? Checking DLL Path C:\Users\<username>\mambaforge\envs\humble\Library\bin for dependencies of rmw_fastrtps_cpp.dll
>>> Found 18 of 19 dependencies in C:\Users\dan\<username>\envs\humble\Library\bin:
['rmw_fastrtps_shared_cpp.dll', 'fastrtps-2.6.dll', 'rosidl_typesupport_fastrtps_c.dll', 'rosidl_typesupport_fastrtps_cpp.dll', 'fastcdr-1.0.dll', 'rmw_dds_common.dll', 'rmw_dds_common__rosidl_typesupport_cpp.dll', 'rmw.dll', 'rosidl_runtime_c.dll', 'rcutils.dll', 'MSVCP140.dll', 'VCRUNTIME140.dll', 'VCRUNTIME140_1.dll', 'api-ms-win-crt-runtime-l1-1-0.dll', 'api-ms-win-crt-heap-l1-1-0.dll', 'api-ms-win-crt-stdio-l1-1-0.dll', 'api-ms-win-crt-string-l1-1-0.dll', 'api-ms-win-crt-math-l1-1-0.dll']
>>> Did not find these DLLs in C:\Users\<username>\mambaforge\envs\humble\Library\bin:
['KERNEL32.dll']
This documentation points at the need for Visual C++ Redistributable Packages for Visual Studio 2013 to supply msvcr20.dll
for FastRTPS.
via
https://github.com/ros2/ros2/issues/708
I tried installing that (Windows Installer) but no luck. Will try to restart and check again.
EDIT: I restarted with no-luck and re-ran the Visual C++ 2013 Redistributable installer again:
Still no change. However, I don't see a msvcr20.dll
in C:\Windows\System32
if that's where it's supposed to be. There, I have only
(humble) c:\Windows\System32>dir msvcr*.dll
Volume in drive C is OS
Volume Serial Number is 2C49-46C0
Directory of c:\Windows\System32
02/01/2002 07:02 PM 829,264 msvcr100.dll
06/05/2021 08:06 AM 18,928 msvcr100_clr0400.dll
02/10/2016 09:08 PM 963,744 msvcr120.dll
06/05/2021 08:06 AM 993,632 msvcr120_clr0400.dll
06/05/2021 08:05 AM 673,896 msvcrt.dll
5 File(s) 3,479,464 bytes
0 Dir(s) 299,364,794,368 bytes free
I suppose there's a conda-forge
package out there for the VC++ 2013 Redistributables?
Looks like I'm barking up the wrong tree with the VC 2013 stuff.
I checked the dependencies of fastrtps-2.6.dll
and found that it's looking for foonathan_memory-0.7.1.dll
.
Output of dumpbin /dependents fastrtps-2.6.dll
:
However, I have foonathan-memory-0.7.2
installed instead:
(humble) C:\Users\<username>\mambaforge\envs\humble\Library\bin>mamba list | findstr foonathan
foonathan-memory 0.7.2 h57928b3_0 conda-forge
ros-humble-foonathan-memory-vendor 1.2.0 py39he8739fe_1 robostack-humble
Downgrading with mamba install foonathan-memory=0.7.1
doesn't change any other packages and seems to fix the problem:
(humble) c:\code>mamba list | findstr foonathan
foonathan-memory 0.7.1 h57928b3_0 conda-forge
ros-humble-foonathan-memory-vendor 1.2.0 py39he8739fe_1 robostack-humble
(humble) c:\code>ros2 topic list
/parameter_events
/rosout
@traversaro Do you have the RMW_IMPLEMENTATION
env variable set? I have:
(humble) c:\code>set | findstr RMW
RMW_IMPLEMENTATION=rmw_fastrtps_cpp
Great debug! The issue then is that the run_exports for foonathan-memory should be stricter: https://github.com/conda-forge/foonathan-memory-feedstock/blob/47bf93075f75cc4645b5c77f9a26bb9b84697242/recipe/meta.yaml#L21 . This is because the library has a form of manual soversion by changing the library name: https://github.com/foonathan/memory/blob/f75c9fc761fde7fa0f6a829df08ea0041ebf1f10/src/CMakeLists.txt#L109 .
Can confirm that the foonathan-memory
downgrade allows me to load my rosbag in my Jupyter notebook.
So ultimately, I think there was an uninformative error on a chain of DLL loads here, and lots of red herrings.
I've unset RMW_IMPLEMENTATION
now (with foonathan-memory 0.7.1
) and the notebook works fine.
If I upgrade foonathan-memory
back to 0.7.2
commands like ros2 topic list
work fine without RMW_IMPLEMENTATION
env variable set.
However, actually reading my rosbag crashes. 😓
https://github.com/conda-forge/foonathan-memory-feedstock/pull/7 should fix the issue for future builds, but for past build we should pepare a repodata patch and submit a PR to https://github.com/conda-forge/conda-forge-repodata-patches-feedstock, something like https://github.com/conda-forge/conda-forge-repodata-patches-feedstock/pull/286 .
but for past build we should pepare a repodata patch and submit a PR to https://github.com/conda-forge/conda-forge-repodata-patches-feedstock, something like conda-forge/conda-forge-repodata-patches-feedstock#286 .
Actually, this is unfortunatly not the case. In the robostack-humble
channel, we are not using the fastrtps
conda-forge package, but a custom ros-humble-fastrtps
(an instance of the more general problem discussed in https://github.com/RoboStack/robostack.github.io/issues/17 .
As as far as I know we do not have any repodata patch infrastructure on robostack, the proper way of solving the problem is to rebuild the ros-humble-fastrtps
package.
I triggered a rebuild of ros-humble-fastrtps
on Windows. I'm not sure whether other platforms need rebuilding, too.
I tried to update --all
tonight, but ros-humble-fastrtps
isn't one that got updated.
Tonight's revision:
I'm on
ros-humble-fastrtps 2.6.2 py39hf2f0fb7_1 robostack-humble
Will check again later. Is there anything else I need to do to try testing an update?
I was sneaky - I overwrote ros-humble-fastrtps
. So you will need to uninstall and re-install unfortunately ..
Ok will try that 👍🏻
Uninstalled and reinstalled ros-humble-fastrtps
and those things that depended on it. (Also ran mamba clean --all
to make sure I didn't reinstall cached packages) and now it's working fine with foonathan-memory 0.7.2
👍
@traversaro @Tobias-Fischer This actually seems to be an issue on linux-64
as well if I export RMW_IMPLEMENTATION=rmw_fastrtps_cpp
explicitly in my env variables:
(humble) dan@<computer>:~$ ros2 topic list
[ERROR] [1663265938.869761742] [rcl]: Error getting RMW implementation identifier / RMW implementation not installed (expected identifier of 'rmw_fastrtps_cpp'), with error message 'failed to load shared library 'librmw_fastrtps_cpp.so' due to dlopen error: libfoonathan_memory-0.7.1.so: cannot open shared object file: No such file or directory, at /opt/conda/build_artifacts/ros-humble-rcutils_1656763445540/work/ros-humble-rcutils/src/work/src/shared_library.c:99, at /opt/conda/build_artifacts/ros-humble-rmw-implementation_1659331744961/work/ros-humble-rmw-implementation/src/work/src/functions.cpp:65', exiting with 1., at /opt/conda/build_artifacts/ros-humble-rcl_1659332063789/work/ros-humble-rcl/src/work/src/rcl/rmw_implementation_identifier_check.c:139
The error is a lot more informative on Linux.
By default Linux was using rmw_cyclonedds_cpp
, which I don't THINK is supposed to be the default:
https://www.eprosima.com/index.php/company-all/news/270-ros2-humble-comes-with-fast-dds
This is now working fine with the fresh builds, at least on Linux. However, see RoboStack/ros-noetic#30
Hi @danzimmerman, could you please let us know whether this is still an issue with the new builds in the robostack-staging channel?
@Tobias-Fischer Sure, happy to. I just tried it with these channels:
(humble-staging) C:\code\ros>conda config --show channels
channels:
- robostack-staging
- conda-forge
and
mamba install ros-humble-desktop
But I can't find the desktop package. Do I need to wait a while for it to propagate?
Encountered problems while solving:
- nothing provides requested ros-humble-desktop
Sorry, still working on ros-humble-desktop on Windows. However, https://anaconda.org/robostack-staging/ros-humble-rosbag2-py is available which should be enough to test this particular issue?
Seems to work fine here to import rosbag2_py
. Also was able to install ros-humble-ros-core
and verify that topic listing was working.
Didn't get a chance to actually open a bag file yet, which seemed to also give me some trouble. I'll try some other things later when I get a chance, but the basics seem to be working.
Ok - let’s close here then, if you have rosbag troubles please open a separate issue.
Issue
I installed ROS2 Humble on Windows today and had an issue locating the FastDDS RMW implementation.
To reproduce the error, it's sufficient to
import rosbag2_py
in Python. (EDIT: and, apparently, have theRMW_IMPLEMENTATION
environment variable set tormw_fastrtps_cpp
, see final comments below)The error kills the Python interpreter as well ("Kernel has died" in Jupyter or a silent exit from a Python prompt)
I have two older installs where this does not seem to have been a problem.
On one of the older installs and this fresh install, there is a
rmw_fastrtps_cpp.dll
in theC:\Users\<username>\mambaforge\envs\humble\Library\bin
, but it seems like the fresh install can't find it (or maybe it is returning the wrong identifier?)On the broken machine, I tried installing Fast DDS with the Windows installer from the eProsima website, which does resolve the error (installs the required files and sets
FASTRTPSHOME
environment variable). However, I didn't recall needing to do this in the past on the other working machines, and the working machine I have access to right now doesn't have it explicitly installed.On the broken machine, the problem returns when I uninstall it.
Broken Config Details
DLL Path is
"C:\Users\<username>\mambaforge\envs\humble\Library\bin\rmw_fastrtps_cpp.dll"
mamba info
Output:mamba list | findstr fastrtps
- Focused packages:mamba list
- All packages:Working Config Details
DLL Path:
"C:\Users\<username>\mambaforge\envs\humble\Library\bin\rmw_fastrtps_cpp.dll"
mamba info
Output:mamba list | findstr fastrtps
- Focused packages:mamba list
- All packages:Broken Config Setup
I followed the "Getting Started" Instructions with the following mods to add the
robostack-humble
channel (maybe I should delete some others?)Then I updated the environment to add some customizations
mamba env update -f notebook_updates_humble.yaml
wherenotebook_updates_humble.yaml
contains: