I am using gdb 7.7.1 on ubuntu, GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1.
My terminal is Konsole 2.13.2.
The problem I am having is, when I go to the TUI mode, after one or two debugger sessions - session, I mean, set breakpoint, run, step over a while and finally kill it by "kill" command - the output starts messed up. Supposedly each output should go to a new line, but now they just all scramble, one immediately after another one.
I attach a screenshot.
I have to quit GDB, open a new terminal tab and start gdb again.
I tried "ctrl-x-a" back and forth, does not help; neither does "ctrl-l".
A while back, I was using another terminal, it also had this problem.
Any help is appreciated.
It appears that your tty settings changed, in much the same way that tty -onlcr might change them (tty onlcr restores the default). Perhaps the code you're debugging changes tty settings, and doesn't get a chance to restore them because of a crash.
As suggested in a comment, using a separate window might provide a workaround.
Related
I am running VSCode in Ubuntu to debug a C++ program. Debugging a console app with GDB is working fine except I really want to capture the console log output to a file. I cannot see a way or option to do this. Is there any option to capture this console log output?
Since there does not seem to be a native feature to save the output of a VSCode terminal, maybe you can use in said terminal a command allowing you to save that session.
See for instance "Gdb print to file instead of stdout"
gdb core.3599 -ex bt -ex quit |& tee backtrace.log
As mentioned, the output is written to backtrace.log and also on the screen.
As the OP Andy Tomlin mentions in the comments, this is not compatible with a debugger session.
We solved the problem by just handling it inside the app and redirecting cout internally to a file.
Background
I am currently trying to build an autonomous drone using ROS on my Rapsberry Pi which is running an Ubuntu MATE 16.04 LTS. Solving the Computer Vision problem of recognising red circles as of now.
Specific Problem
I am constantly getting the error I get in this question. To help me solve this, I have decided to use gdb. However, the command rosrun --prefix 'gdb run --args' zlab_drone vdstab does not seem to be working for me. zlab_drone is the name of the package and vdstab is the name of the executable I am trying to run. Since this is inside a ROS environment, I have grabbed the syntax from here, and used the suggestions in this question.
When I invoke this command, even with tui, I get a SIGSEGV and when I invoke list inside gdb itself, the program does not stay at a particular point and keeps listing a different line till it is out of range. This is quite a weird issue.
I managed to make it work without this issue earlier by using a different command, I reckon. I just cannot remember how I made it work last time.
Well, in the link you mentioned, it states clear that you should use either :
launch-prefix="xterm -e gdb --args" : run your node in a gdb in a separate xterm window, manually type run to start it
or :
launch-prefix="gdb -ex run --args" : run your node in gdb in the same xterm as your launch without having to type run to start it
So, it really looks like you missed an -ex as #ks1322 suggeseted in the comments or just type run to start the debug process.
I found out about this exclusive bug that relates to Raspberry Pi's solely. Basically the solution involves, as quoted by Peter Bennet:
There is a workaround. Start the program, then from another command
prompt or from an ssh remote login, use gdp -p xxxxx where xxxxx is
the process number. This works without crashing. If you need to debug
something that happens before you can get in from another command
prompt, add to the program a command that stops process at the
beginning of main, for example a call to gets, which will wait for you
to press enter before continuing.
When I try to use the debugger on a simple test project the console dumps out the following:
warning: `/var/folders/s1/dxx9glzn45j6x2ypzk9xkjnc0000gp/T/Test-0061ba.o': can't open to read symbols: No such file or directory.
$1 = 0xff
The target endianness is set automatically (currently little endian)
No symbol table is loaded. Use the "file" command.
Launching the debugger gets 99% complete and gets stuck! It just hangs there for awhile and when I try to terminate the connection nothing happens. Then when I go to shut down eclipse I usually have to force quit it :( Anyone have any ideas?
I fixed this issue by correcting the gdb-cert. Make sure you select code signing "Always trust"
A while ago I changed my personal operating system to linux and my development enviroment to KDevelop.
However debugging c++ projects is still not working as it should.
My KDevelop version is 4.2.2 (I installed it through package management)
Every time I hit the "debug button" the application is starting with the console message
warning: GDB: Failed to set controlling terminal: Operation not permitted and debugging functionality is not available.
Any ideas welcome.
(If you need additional information don't hesitate to ask)
I also had this problem, but I use gdb in KDevelop sparsely enough that hadn't bothered me yet. Here's my log of trying to fix it:
Grepping through the GDB 7.3.1 source code reveals that this message is printed when GDB tries to set its master TTY to a newly-created pseudo-tty (see gdb/inflow.c, lines 683-740). In particular, a call to ioctl with request TIOCSCTTY fails with a permissions error.
With this in mind, I took a look at the Linux kernel source code to see what could cause a failure. A bit of searching shows that it will eventually degenerate into a call to tiocsctty(). The comment from tiocsctty that is important here:
/*
* The process must be a session leader and
* not have a controlling tty already.
*/
Since the only other reason it can fail with EPERM is if the tty that GDB creates is actually a controlling tty for another process (which seems highly unlikely), I thought it reasonable to assume that GDB is not a session leader. Fair enough, it's launched by KDevelop after all!
So: I tried not launching the GDB session in an external terminal, and it works. Problem narrowed down.
Originally, the external terminal line was set to konsole --noclose --workdir %workdir -e %exe. Changing this to terminator -e %exe made a slight difference: KDevelop warned me that
GDB cannot use the tty* or pty* devices.
Check the settings on /dev/tty* and /dev/pty*
As root you may need to "chmod ug+rw" tty* and pty* devices and/or add the user to the tty group using "usermod -G tty username".
I checked my permissions; my user was part of the tty group and all relevant files were readable and writable.
Grepping through the KDevelop source code reveals how KDevelop actually sets up the terminal. It runs the shell script
tty > FIFO_PATH ; trap "" INT QUIT TSTP ; exec<&-; exec>&-; while :; do sleep 3600;done
and then sets up GDB to use the terminal device it reads from FIFO_PATH. (My name, by the way, not the one that KDevelop uses.) The problem (as best I can tell) is that gdb is not launched as a child of the shell script, and thus cannot use it as its main tty.
I'm not feeling up to patching KDevelop to make this work properly as of yet (or finding what actually caused this to stop working in the first place . . .), so the best I can suggest at the moment is to simply not use an external terminal for debugging purposes.
Good luck! I'll update if I find anything useful.
As Arthur Zennig said, for more information, you need to do something
Firstly, you need to create the Terminal profile
Secondly, open Launch Configurations, fill info such as the image below
Good luck!
In case you got the error:
"Can't receive konsole tty/pty. Check that konsole is actually a
terminal and that it accepts these arguments"
RUN > CONFIGURE LAUCHERS > (See picture below. My project name was "loops")
What worked for me was to uncheck checkbox "Use External Terminal". Found the in the "Compiled Binaries" Tab.
I'm trying to debug a server I wrote with gdb as it segfaults under very specific and rare conditions.
Is there any way I can make gdb run in the background (via quiet or batch mode?), follow children (as my server is a daemon and detaches from the main PID) and automatically dump the core and the backtrace (to a designated file) once the program crashes?
Assuming you have appropriate permissions, you can have gdb attach to any process. You can do it on the command line with:
gdb /path/to/binary _pid_
or from within gdb with the attach command:
attach _pid_
So, once your daemon has started, you can use either of these techniques to attach to the final PID your daemon is running as. Attaching gdb stops the process which you are tracing so you will need to issue a "continue" to restart it.
I don't know a direct way to get gdb to run arbitrary commands when the program crashes. Here is one workaround I can think of:
Create and register a signal handlers for SIGSEGV.
Tell gdb not to stop on that signal (handle SIGSEGV nostop)
Set a breakpoint at the first line of your signal handler.
Assign commands to the breakpoint from step 3
Why not just run the process interactively in a persistent screen session? Why must it be a daemon when debugging? Or just run gdb in the screen session and attach it to the running process (e.g. gdb /path/to/binary -p PID_of_binary) after it forks.
First, I'd setup your shell / environment to give you a core dump. In bash:
ulimit -c unlimited
Once you have the core dump, you can use gdb to examine the stack trace:
gdb /path/to/app /path/to/core/file
I'm not really a gdb expert but two things come to mind
Tracepoints which might give you the necessary information as your program runs or
Use gdb's remote debugging facility to debug your program while it's running as a daemon.
How to generate a stacktrace when my gcc C++ app crashes answer for this question should do what you want. (assuming you can make changes in your code)
You might want to take a look at how Samba facilitates debugging; it has a configurable "panic action" that can suspend the application, notify the developer, spawn gdb, etc., and is run as part of its signal handler. See lib/util/fault.c in the Samba source tree.
My practice: comment out daemon function call, rebuild binary, then use gdb to run.