Geek Answers Handbook

Debugging an ncurses application using gdb

I am trying to debug an ncurses application using gdb. I use the tty command to redirect software I / O to another terminal. The output works like a charm, but I have input problems. I am using the getch () function to extract characters in my application. So, for example, if I do gdb in my session:

tty /dev/pts/5

I get my output in another tab of my terminal (gnome-terminal). My gdb sessions are stuck waiting for input, but when I press any key in my / dev / pts / 5, I get it printed, but the application itself does not exclude it as an input character. When working without gdb everything works fine, I also use noecho (), so the characters should not be displayed. So what is the problem? Is it possible to somehow handle input from a redirected terminal?

+5
source share
2 answers

You can connect to the process for debugging from another terminal instead of trying to start the application from gdb .

Run the process as usual. When it is locked for user input, find its process id and then attach it to gdb from another window:

 gdb -p <PID>

Your problem is that the program is still expecting its interactive input to be received from the gdb session.

+9
source

Maybe it’s a bit late to answer, but I hope this helps: It took some time to figure out how to debug ncurses applications, finally I made a very convenient way using gdbserver and tmux.

Thus, gdb I / O and applications are completely separate:

debug.sh (script that starts debugging):

 #!/bin/bash tmux splitw -h -p 50 "gdbserver :12345 ./yourapplication" tmux selectp -t 0 gdb -x debug.gdb

debug.gdb (single line gdb script file for convenience):

 target remote localhost:12345

Thus, the application starts on the right side, gdb on the left is waiting to click continue or any other ordinary gdb stuff :)

As soon as you exit, tmux automatically closes gdbserver (and therefore the right panel), and that’s all :)

0
source

More articles:


All Articles