| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
Hi, all
I want to integrate ROS with Qtcreator. When I use Qtcreator to debugging the existing ROS package, I met this problem: Lowest section in /usr/lib/libicudata.so.42 is .note.gnu.build-id at 000000f4 Anyone knows how to solve this problem? And is there anyone that using ROS with Qtcreator successfully?
Thanks Tony
QtCreator is a good choice for ROS related development as it natively "understands" CMake projects. For easy debugging, the relevant node can be compiled as "Debug" or "RelWithDebInfo" and then started normally via a launch file. One can then attach the QtCreator debugger to the running node via "Debug"->"Start Debugging"->"Attach to running external Application...". This works very well for me and has the advantage that one does not have to setup parameters/remappings etc. for the node in a separate step.
/edit: It is required to follow the instructions in the answer here if one gets a "ptrace operation not allowed" error.
Edit: To make debug build add set(CMAKE_BUILD_TYPE Debug) to CMakeLists.txt
Hi Stefan, I tried to do just as you say, but I'm having problems with ptrace not being allowed. Also, doesn't this mean you cannot set breakpoints from QtCreator? If I try to debug the relevant node from QtCreator itself it seems to get stuck in "Setting breakpoints...", though...
I've been digging a bit deeper and it seems that I can start the debugging from the QtCreator interface, set breakpoints and so on, and everything goes fine until I reach a ros::spin() call. Any idea why this might be?
If you set from CMakeLists.txt, you have to omit the D in front of CMAKE_BUILD_TYPE. Only when setting the definition from command line (e.g. "catkin_make -DCMAKE_BUILD_TYPE=Debug") you have to add it.
@Stefan Kohlbrecher thanks it worked! As a side note, I had to run qtcreator with "sudo" for the debugging from Qtcreator to work; otherwise it works perfectly.
@jespestana Instead of running qtcreator as sudo, you should allow ptrace of non-child-processes for gdb
sudo apt-get install libcap2-bin
sudo setcap cap_sys_ptrace=eip /usr/bin/gdb
or enable ptrace globally echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope (not recommended)
What @Stefan Kohlbrecher suggests is correct but only partially. Attaching to an external process is an option and in fact it's the only option when you use roslaunch. However hooking to an external process adds an extra layer of complexity and if you can't use ptrace you are basically screwed. If you stick to rosrun you can simply dump the rosrun part and debug your node straight away using the "normal" debug mode in Qt Creator. Why? Because what the node basically is, is a normal application. Rosrun and especially roslaunch simply wrap some ROS functionality (such as passing node parameters via launch files) around it so that it's easier for the user to run nodes. If command line arguments are important for your node, you can modify your node to get those from pure argv (not through the NodeHandle) or read from a text file.
That's why I wrote "for easy debugging" :) You can of course replicate a launch setup via command line (and it's good you explicitely describe how), but this is relatively unwieldy for complex setups.
Asked: 2012-05-27 03:29:46 -0500
Seen: 11,892 times
Last updated: Aug 27 '15
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
