Issue with ROS examples - Segmentation Fault

[juju]

Good morning,

Thank you very much for your wonderful open-source simulator!

I have an issue with the ROS examples. The compilation is successful, however, when I execute the program, I get a segmentation fault. I am using the commit 8995d62963e9d6ef6c58985a2601d9a80d48fba7 on the branch main (not the latest because I have meshes visualisation troubles).

During the CMake configuration, I receive the following warning:

CMake Warning at CMakeLists.txt:96 (add_executable): Cannot generate a safe runtime search path for target custom_handler because files in some directories may conflict with libraries in implicit directories: runtime library [libconsole_bridge.so.1.0] in /usr/lib/x86_64-linux-gnu may be hidden by files in: /home/project_chrono/packages/urdf/lib Some of these libraries may not be found correctly.

(the document attached contains the whole terminal output)

I am not sure how to solve this issue and was wondering if this is a known problem.

Thank you very much for your help! :)

[Patrick CHEN]

Hi,

Just because the complex nature of a ROS setup, we will need to know more about your environment and enable extra logging to help you with this.

Are you using Docker(if so please share Dockerfile)? What base OS version are you using(officially ROS2 Humble only support Ubuntu22.04, other version can cause unpredictable issues). 

To collect extra log, please help me with the following:

Use ROS2 Logging, execute line by line in the same folder you build custom_handler:

export RCUTILS_CONSOLE_OUTPUT_FORMAT="[{severity}] [{time}] [{name}]: {message}"

export RCUTILS_LOGGING_BUFFERED_STREAM=1 

export RCUTILS_LOGGING_USE_STDOUT=1 

export RCUTILS_CONSOLE_STDOUT_LINE_BUFFERED=1 

RCUTILS_LOG_MIN_SEVERITY=DEBUG ./custom_handler

Use strace:

strace -f ./custom_handler 2>&1 | tail -50

Use ldd: ldd ./custom_handler | grep "not found" 


Hopefully one of these will yield some insights, please upload the info generated by each debugging step, if not we will go the core dump analysis route.
libconsole_bridge.so is mainly used for ROS2 logging purposes, though it should not happen, it shouldn't be catastrophic and cause a segfault either. We will see if ldd points to this.


Best,
Patrick Chen

Simulation Based Engineering Lab

[juju]

Good afternoon Patrick,

Thanks you very much for your help. 

I used the dockerfile provided in the main branch of project chrono (Ubuntu 22.04 with ROS2 Humble), so I use a container to launch project chrono demos.

I have executed the commands you provided, the results are in the attachment text file. The command strace yields an error about a missing xml file inside build folder. Inside the ros demos folder, I created a build folder then I cmake .. and make with the CMakeLists.txt file in the attachment.

Thank you very much for your help :)

[Patrick CHEN]

Really hate to say this, but I could not replicate this on my end despite running in a clean VM and fresh clone/docker image. I would've guessed based on that log your ROS install was not built correctly, however you are using our dockerfile which as far as I can tell works.

So I need a few more info, which branch of chrono are you attempting this from, please try master if that is not what you used. Are you using a pre-built docker image we published to docker hub or you built from scratch(I assumed you built from scratch, if using pre-built, which tag?).
Did you modify custom_handler.cpp or did it fail as-provided?(if modified and you don't mind please share)

My full step to attempt to replicate(I copied this directly from my bash history):

only step missing here is i changed in chrono/contrib/docker/snippets/chrono.dockerfile in line 5, ARG CHRONO_BRANCH="main"

OS:Ubuntu 22.04, QEMU

```

  724  mkdir troubleshot_chrono_ros
  725  cd troubleshot_chrono_ros/
  726  git clone https://github.com/projectchrono/chrono
  727  ls
  728  cd chrono/contrib/docker/

  729 docker compose build dev

  730 docker compose up dev -d

  731 sudo docker ps
  732 sudo docker exec -it 546 /bin/bash

in container:
chrono@chrono:~/chrono/template_project_ros/build$ history
    1  ls
    2  cd ..
    3  cd chrono
    4  ls
    5  cd template_project_ros/
    6  ls
    7  mkdir build
    8  cd build/
    9  cmake .. -DChrono_DIR=/home/chrono/chrono/build/cmake/ -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS_RELEASE="-O3"
   10  make -j20
   11  ls
   12  ./custom_handler
   13  history

```

Best,
Patrick

[Patrick CHEN]

p.s. Forgot but probably should mention this, the strace log you posted points to ROS2 attempting to load a custom ros middleware configuration and is failing to find it, which is why I guess its a broken ROS2 installation. If you are desperate you can put a placeholder file to see if will get past this, but I recommend us trying to get to the bottom of it.
I also noted that you were running/building the demo from different directory this time than the initial issue, i tried both, and both worked for me.

On Monday, September 8, 2025 at 8:46:52 AM UTC-5 j904...@gmail.com wrote:

[juju]

Hello Patrick,

Apologies for the delayed reply.

After testing many configurations with my Dockerfiles, I've determined that the issue lies with the Chrono::Parsers module. During the CMake configuration step, the parsers module fails to find my ROS 2 installation, even though it is installed correctly.

Here is the relevant output from CMake:

==== Chrono Parsers module ====

-- Found URDFDOM and dependencies

-- URDFDOM include dirs: /home/project_chrono/packages/urdf/lib/urdfdom/cmake/../../../include/urdfdom;/home/project_chrono/packages/urdf/lib/urdfdom_headers/cmake/../../../include/urdfdom_headers

-- Package ROS2 NOT found.

ROS support disabled.

-- Found Python and dependencies

-- Python3_Interpreter_FOUND: TRUE

-- Python3_Development_FOUND: TRUE

--

I have confirmed that the required variables are set in the Dockerfile as specified in the installation guide:

 

# Update CMake options

ENV CMAKE_OPTIONS="${CMAKE_OPTIONS} \

-DCH_ENABLE_MODULE_PARSERS:BOOL=ON \

-Durdfdom_DIR=${PACKAGE_DIR}/urdf/lib/urdfdom/cmake \

-Durdfdom_headers_DIR=${PACKAGE_DIR}/urdf/lib/urdfdom_headers/cmake \

-Dconsole_bridge_DIR=${PACKAGE_DIR}/urdf/lib/console_bridge/cmake \

-Dtinyxml2_DIR=${PACKAGE_DIR}/urdf/CMake"

Separately, I believe I found a typo in the ch_parser.dockerfile on the main branch. It uses DCH_ENABLE_MODULE_PARSER instead of the correct DCH_ENABLE_MODULE_PARSERS, which likely prevents the module from being activated in that file.

I read online that this kind of issue can be caused by not sourcing the ROS environment. I tried sourcing /opt/ros/humble/setup.bash in the same RUN command as cmake, but the parsers module still could not find ROS 2.

If I disable the PARSERS module, ROS module works perfectly, but this prevents me from using URDF files.

Do you have any suggestions on how to resolve this?

Thank you very much for your help :)