ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

gdb: Any way to debug a segfault in a ROS node?

asked 2014-02-17 04:45:03 -0600

courrier gravatar image


After a refactoring of my code, my node segfaults, so I would like to debug it with gdb. I used roslaunch with gdb prefix as indicated in this tutorial.

Nevertheless it seems that I'm able to see the error output. I have removed the "run" parameter to see if I can run it manually, add a breakpoint and so on. It works, but I cannot see neither what I type nor the standard output. For instance if I try typing the unexisting gdb command "hello", I see successfully:

Undefined command: "hello".  Try "help".

But if I run a gdb command that is successfully executed (breakpoint main, print argc, or whatever....), the prompt does not display anything.

I tried gdb --tty /dev/pts/4 but it redirects only my program, so gdb standard input and output are still invisible.

Moreover I get the error warning: GDB: Failed to set controlling terminal: Operation not permitted and also [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]. The last error seems to be a bug of gdb, so I've installed the last version 7.7, it's now solved but I still get the first error and no display except stderr.

What program do you use to debug your nodes? Any tip or trick to redirect the standard input/output in some terminal?

Many thanks

edit retag flag offensive close merge delete



Usually if an application does not crash/segfault's on GDB, it's some sort of race condition. Here some tiny [manual]( from Adobe, how to debug multi-threaded applications with GDB. Also, [Valgrind](‎) should be useful. One more thing, why the hell there are no automatic tests written, huh? You're going to burn in hell forever for missing that. Oh, one more thing. Usually system logs (`dmesg | tail 100`) contains some handy information about segfaults. Oh, another thing - instead of redirecting IO from Your program, You could attach to working process from another terminal with GDB as described here: . `gdb -p <pid_of_the_proccess>`, for short.

Kamiccolo gravatar image Kamiccolo  ( 2014-02-17 05:16:31 -0600 )edit

Are you using the xterm variant from the linked tutorial?

demmeln gravatar image demmeln  ( 2014-02-17 10:02:25 -0600 )edit

3 Answers

Sort by » oldest newest most voted

answered 2014-02-17 07:53:16 -0600

ahendrix gravatar image

It sounds like stdout is being redirected. Have you tried adding the output="screen" option to your node tag?

edit flag offensive delete link more

answered 2014-02-17 19:00:23 -0600

I´d recommend using a GUI for gdb-based debugging, with QtCreator currently being my favorite. A short description of how to use it is available in this answer. If there are underlying issues with gdb on your machine it might not work correctly, however.

edit flag offensive delete link more


And arguments would be...?

Kamiccolo gravatar image Kamiccolo  ( 2014-02-17 20:57:21 -0600 )edit

There are no arguments, just launch via launch file as usual and attach to the process (or at least that´s the easiest option).

Stefan Kohlbrecher gravatar image Stefan Kohlbrecher  ( 2014-02-17 23:19:12 -0600 )edit

@Stefan Kohlbrecher, the same You can do with console one. Which does not require sticking to specific IDE.

Kamiccolo gravatar image Kamiccolo  ( 2014-02-18 03:28:36 -0600 )edit

Sure, my point was that point and click using a UI is easier for most people as they don´t have to memorize gdb commands :) If you´re already proficient with using gdb from the command line that point is moot of course.

Stefan Kohlbrecher gravatar image Stefan Kohlbrecher  ( 2014-02-18 05:10:29 -0600 )edit

answered 2014-02-17 22:25:50 -0600

courrier gravatar image

updated 2014-02-17 22:42:32 -0600

Thanks, great, output="screen" works perfectly, I can see my gdb back!

Thanks for the tiny manual, I keep it in my bookmarks.

why the hell there are no automatic tests written, huh?

Well, I'm just prototyping a node, I do not even know if we will keep this part of the project, I reserve tests for the future ^^

While I've set ROS_BUILD_TYPE to Debug in CMakeList, but gdb says (no debugging symbols found). What am I missing there? I self-reply: My CMakeCache was overidding CMakeList. Setting CMAKE_BUILD_TYPE:STRING=Debug is ok!

My bug seems to be an insertion of an uninitialized object in a std::vector<>

Many thanks to you all and to gdb!

edit flag offensive delete link more



Two small notes: 1. You should edit Your original question or add another one for debug messages issues. Also, accepting finally a good answer is appreciated :) 2. Valgrind usually helps with uninitialized data bugs :)

Kamiccolo gravatar image Kamiccolo  ( 2014-02-17 22:48:45 -0600 )edit

Question Tools

1 follower


Asked: 2014-02-17 04:45:03 -0600

Seen: 4,847 times

Last updated: Feb 17 '14