Ask Your Question

Segmentation Fault with SendingGoal Client and actionlib

asked 2020-04-09 16:20:11 -0500

Marcus Barnet gravatar image

updated 2020-04-11 07:49:12 -0500

I'm using Melodic, Ubuntu 18.04 and I'm trying to run a sample code for a basic C++ SimpleActionClient, it compiles correctly but when I run it I immediately get:

rosrun beginner_tutorials send_goal
Segmentation fault (core dumped)

the line that generates the error is this one:

  actionlib::SimpleActionClient<beginner_tutorials::PointAction> ac("planner", true);

and I cannot understand the reason since it is the same used in the tutorial.

This is my code:

#include <ros/ros.h>
#include <actionlib/client/simple_action_client.h>
#include <actionlib/client/terminal_state.h>
#include <beginner_tutorials/PointAction.h>

    int main (int argc, char **argv)
      ros::init(argc, argv, "planner");

      // create the action client
      // true causes the client to spin its own thread
      actionlib::SimpleActionClient<beginner_tutorials::PointAction> ac("planner", true);
      ROS_INFO("Waiting for action server to start.");
      // wait for the action server to start
      ac.waitForServer(); //will wait for infinite time

      ROS_INFO("Action server started, sending goal.");
      // send a goal to the action
      beginner_tutorials::PointGoal goal;
      goal.x = 20;

      //wait for the action to return
      bool finished_before_timeout = ac.waitForResult(ros::Duration(30.0));

      if (finished_before_timeout)
        actionlib::SimpleClientGoalState state = ac.getState();
        ROS_INFO("Action finished: %s",state.toString().c_str());
        ROS_INFO("Action did not finish before the time out.");

      return 0;

Why the segmentation fault is generated and how can I solve it? Thank you!


I compiled the code in DEBUG mode by using catkin_make:

catkin_make -DCMAKE_BUILD_TYPE=Debug

and then I run gdb in this way:

rosrun --prefix 'gdb --args' beginner_tutorials send_goal 
GNU gdb (Ubuntu 8.1-0ubuntu3.2)
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/isola/catkin_ws/devel/lib/beginner_tutorials/send_goal...done.
(gdb) run
Starting program: /home/isola/catkin_ws/devel/lib/beginner_tutorials/send_goal 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/".
[New Thread 0x7ffff1418700 (LWP 39204)]
[New Thread 0x7ffff0c17700 (LWP 39205)]
[New Thread 0x7fffebfff700 (LWP 39206)]
[New Thread 0x7fffeb7fe700 (LWP 39207)]
[New Thread 0x7fffeaffd700 (LWP 39208)]

Thread 6 "send_goal" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffeaffd700 (LWP 39208)]
0x00007ffff6a9af63 in ?? () from /usr/lib/x86_64-linux-gnu/

but it says the send_goal generates a SIGSEGV which is something we already know. How can I go deeper into the problem?

This is what happens if I set a breakpoint:

(gdb) break SimpleActionClient
Breakpoint 1 at 0x8c4ae: file /opt/ros/melodic/include/actionlib/client/simple_action_client.h, line 93 ...
edit retag flag offensive close merge delete



Make sure you have no outstanding updates on ROS packages, and after you've made sure, completely clean your workspace (ie: catkin clean -y when using catkin_tools, or rm -rf devel build install in the root of your catkin_ws when using catkin_make), then rebuild your workspace.

Unexplainable SEGFAULTs can sometimes be caused by binary incompatibilities.

gvdhoorn gravatar image gvdhoorn  ( 2020-04-10 07:46:24 -0500 )edit

I got always the same error! Nothing changed! is anything else I can check to understand why I get that error?

Marcus Barnet gravatar image Marcus Barnet  ( 2020-04-10 09:54:45 -0500 )edit

As always with SEGFAULTs: build everything in Debug mode and run the binary in gdb (or use the equivalent functionality of your IDE, if you're using one).

gvdhoorn gravatar image gvdhoorn  ( 2020-04-10 10:42:34 -0500 )edit

I followed your suggestion on this #q200155 and I tried to use gdb, but this didn't add useful information to my problem since it only says that there is a SIGSEGV error. I added the output of gdb in my first post.

Marcus Barnet gravatar image Marcus Barnet  ( 2020-04-10 11:03:54 -0500 )edit

You'll need to ask gdb to print a backtrace for you. After you get the prompt, enter bt and then press enter.

Note: it's not going to magically solve things for you. It'll only provide you more information on where the SEGFAULT happens. It'll still be up to you to figure out what is going on then.

gvdhoorn gravatar image gvdhoorn  ( 2020-04-10 12:25:54 -0500 )edit

I found out that it is not a code error since I'm able to correctly build and run the same node on another computer with same Ubuntu version and ROS. How is it possible?

Marcus Barnet gravatar image Marcus Barnet  ( 2020-04-11 06:40:09 -0500 )edit

My guess would still be an ABI issue, due to ABI incompatibilities between packages you have installed on the machine it crashes on.

Note that initially I only thought about deb packages, but it could really also be anything you've installed on your machine.

Did you ever build anything from source? A Boost version perhaps (installed in /usr/local)? Or something a driver for some piece of hw installed? Do you happen to have any custom versions of ROS packages in your workspace?

If those get linked in before the one the default ROS packages link to, SEGFAULTs are almost bound to happen.

You could compare the output of ldd /path/to/your/crashing/binary on both the machine on which it crashes, adn the one on which it doesn't.

gvdhoorn gravatar image gvdhoorn  ( 2020-04-11 06:43:01 -0500 )edit

I've added the outputs of the ldd command on both systems. It seems that the Boost version is the same on both the machines.

Marcus Barnet gravatar image Marcus Barnet  ( 2020-04-11 07:42:12 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2020-04-12 07:20:07 -0500

Marcus Barnet gravatar image

I solved it. The problem was related to libboost-dev version since there were two library versions installed in the system. I removed the version 1.71 and I reinstalled ROS from apt-get and this solved the issue. Now the code works fine also with the emulated Ubuntu system.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2020-04-09 16:20:11 -0500

Seen: 42 times

Last updated: Apr 11